The element can now be customized with CSS • Hacker News Board

Re: The <select> element can now be customized with CSS

#191

Post by afiori » Thu, Apr 03, 2025, 6:24 PM UTC

cush wrote: post #76

dbbk wrote: post #52

Earlier quoted context omitted.

Definitely not. Why would they let web devs render outside of the browser window? That's a recipe for disaster.

There needs to be some middle ground. I'd trade off just being able to set just the background color and font and keep these native-like features

I think that you can compose arbitrary images that way using an image-like font (using various Unicode chars and assigning to each a small tile of the full image)

Actually I am now curious of how much detail/size/colours/animations you can fit in a single letter.

Re: The <select> element can now be customized with CSS

#192

Post by afiori » Thu, Apr 03, 2025, 6:29 PM UTC

immibis wrote: post #138

caesil wrote: post #49

Earlier quoted context omitted.

I don't think browsers will ever let web code affect things outside the viewport because scammers would cook up some truly zany things with that power.

Even rendering arbitrary pixels inside the viewport is bad enough. Something that went out of fashion but is apparently now back in fashion is detecting the user's operating system and browser, then displaying a pixel-perfect replica of a second browser window open to Paypal and asking you to log in... displayed within the bounds of the first browser window.

This is why the new login prompt of 1Password is worse than the old one, it appears at the center of the screen where the website could easily put a replica. The old one opened at the height of the extension icon, a bit above where the browser opens the alert dialog

Re: The <select> element can now be customized with CSS

#193

Post by progmetaldev » Fri, Apr 04, 2025, 4:00 AM UTC

mason55 wrote: post #177

progmetaldev wrote: post #130

Earlier quoted context omitted.

For this case, I will often ask for the timezone, since that data is often updated on the operating system, but I don't believe it's often for someone to be in the same location and have their timezone change. The software that I've maintained the most over the years (since 2009 up to deploying an update today) requires a login, so I have a client account that includes choosing their timezone. I then use that to conv…

This works for things in the past but not things in the future. If I say I want something to happen at 8pm New York City time on January 7, 2028 and then the DST rules for NYC change, I likely still want it to happen at 8pm. Converting to UTC and back to local time loses that information and it will happen at the wrong time.

I 100% agree with you, and don't set cron jobs/scheduled tasks this way. I only use this for displaying date/time to users.

With that said, I do appreciate the comment, and would have to make sure that if I run scheduled tasks in the future, they are run when the user wishes them to be completed based on when that user sets it to be completed (so would most likely not convert to UTC, and save the timezone with the date/time).

Re: The <select> element can now be customized with CSS

#194

Post by preisschild » Fri, Apr 04, 2025, 7:18 AM UTC

progmetaldev wrote: post #130

sublinear wrote: post #118

Earlier quoted context omitted.

ISO-8601 is not the correct format for serializing local time unless it's in the past. In my experience, a local datetime picker is going to be used almost exclusively for a future date and time. What you want instead of a timezone offset is a zone ID. That way date and tzdata can handle it properly on the backend.

For this case, I will often ask for the timezone, since that data is often updated on the operating system, but I don't believe it's often for someone to be in the same location and have their timezone change. The software that I've maintained the most over the years (since 2009 up to deploying an update today) requires a login, so I have a client account that includes choosing their timezone. I then use that to conv…

I'd much rather have it just use the system time, which is already available over a javascript API. I wish it just were included in your html form datetime-local request.

https://caniuse.com/mdn-javascript_builtins_intl_datetimefor...

or appending the `Date().getTimezoneOffset();` to receive a ISO8601 timezone offset