10 ms·

The fact that I'm disproportionally excited about this probably dates me as an early 2000s web developer. But since selects can do things that you simply cannot

The fact that I'm disproportionally excited about this probably dates me as an early 2000s web developer. But since selects can do things that you simply cannot recreate in HTML, e.g. have options drop downs that extend outside the viewport boundaries, makes this a really helpful feature. Now, do autocompletes and tag selectors next...

majora2007 1y ago
It's actually crazy that we don't have a basic typeahead component or tag selector in this day and age with HTML. Every web page I've ever built has needed these components and while there are libraries out there, they all have an annoying bug here or there. But considering we are just now getting Select tags with styling, signals how long it might take for a typeahead which is vastly more complex.
- jhardy54 1y ago
  > basic typeahead It isn’t perfect, but have you tried <datalist>? Totally agree about tag pickers, I was bummed to see that Bootstrap didn’t have a tag selector component either.
  - mlhpdx 1y ago
    I have, and failed. See https://news.ycombinator.com/item?id=40265782 https://news.ycombinator.com/item?id=40265782
    - recursive 1y ago
      Safari is the "new" IE. I put "new" in quotes because it's been this way for like a decade.
      - facile3232 1y ago
        If anything chrome is the engine with odd quirks you are forced to work around.
        recursive 1y ago
        I haven't found this to be the case in my experience.
        facile3232 1y ago
        Maybe it's just iframes that are the issue but they were a devil and a half to get working in chrome (or blink ig) without relying on third party cookies.
        progmetaldev 1y ago
        Interested in what you are doing with the iframes. Something with complex authentication? I've been forced to use iframes a few times for 3rd party resources that should have been first-party (mostly with banks and credit unions), and have only had some styling issues on mobile (which have been overcome by using JavaScript and window.matchMedia to check for media queries).
        immibis 1y ago
        Chrome's quirks become the standard and other browsers have to implement them.
      - troupo 1y ago
        --- start quote --- Back fifteen years ago IE held back the web because web developers had to cater to its outdated technology stack. “Best viewed with IE” and all that. But do you ever see a “Best viewed with Safari” notice? No, you don’t. Another browser takes that special place in web developers’ hearts and minds. --- end quote --- https://www.quirksmode.org/blog/archives/2021/08/breaking_the_we.html https://www.quirksmode.org/blog/archives/2021/08/breaking_th...
        recursive 1y ago
        Yes, Safari is not exactly like IE because IE had a dominant user share once upon a time. We don't see "best viewed in Safari", but we do see plenty of sites that can be viewed in Safari, despite the extra effort used to get them there. And I'm not even a regular chrome user.
        troupo 1y ago
        The absolute vast majority of web sites require no effort to "get there". The absolute vast majority of those which don't work in Safari use Chrome-only non-standards. And there is a tiny minority of sites that run into some Safari-specific quirks
    - deleted 1y ago
      [deleted]
    - ricenews 1y ago
      It may not be present in Apple’s official documentation but it has been supported since Safari 12.2. See https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da... compatibility. The demo on that page works for me in current Safari on both iOS and Mac.
      - no_wizard 1y ago
        Some examples seem to work better than others though. I’m on latest iOS and sometimes it will invoke the native date picker like you’d expect to see, sometimes it won’t, and the type ahead doesn’t seem to work consistently
      - mlhpdx 1y ago
        That demo shows the problems splendidly. It “only kinda” works on iOS.
- asddubs 1y ago
  also drag and drop rearrange
- cosmic_cheese 1y ago
  Why implement broadly useful HTML widgets when you can instead put those engineering resources to work on a new WebBeer API that fetches the number of beers in the user’s fridge or something else similarly niche?
renerick 1y ago
> have options drop downs that extend outside the viewport boundaries Unless this is about something different from what you mean, unfortunately, it's not the case, as stated in the article: > Using base-select loses a number of features and behaviors: > The <select> doesn't render outside the browser pane.
asddubs 1y ago
I doubt it'll still be able to do those things. From the article: >Using base-select loses a number of features and behaviors: > The <select> doesn't render outside the browser pane. > It doesn't trigger built-in mobile operating system components. I have mixed feelings about it. Mobile users, get ready for poorly optimized select elements. On the other hand it reduces the need for javascript for styling forms, which is good
- wolframhempel 1y ago
  That's fair, but I assume that is the initial implementation. Surely, over time, browser vendors will want to make the full spectrum of select functionality available consistently.
  - caesil 1y ago
    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.
    - immibis 1y ago
      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.
      - afiori 1y ago
        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
  - dbbk 1y ago
preisschild 1y ago
<input type="datetime-local"> with automatic ISO8601 timezone offsets would be awesome too!
- sublinear 1y ago
  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.
  - progmetaldev 1y ago
    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 convert everything to UTC in the database, and when I retrieve the data, I use it to convert UTC back to their local date/time. I felt that it was the best option, since a user moving to a different timezone should still be able to get dates/times back relative to where they have their current timezone set.
    - mason55 1y ago
      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.
      - progmetaldev 1y ago
        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).
kkarpkkarp 1y ago
> Now, do autocompletes This is kind of ready, see datalist element. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...
- porridgeraisin 1y ago
  I know about datalist, but it's the saddest autocomplete experience you can offer. If something is not fully styleable, it's automatically garbage. If it's styleable, it may be decent. Now, I understand why datalist is not styleable the way it is implemented right now. On Android, the suggestions come on the top bar of the native keyboard, so it doesn't make sense to be able to put arbitrary divs there. But in that case, there should be an alternative styleable autocomplete element. Another element that is unstyleable crap is <input type=file>, <audio> too.
blatantly 1y ago
Ooh I can render arbitrary pixels outside the viewpoint. Like a system dialog asking for a password.

majora2007 1y ago

It's actually crazy that we don't have a basic typeahead component or tag selector in this day and age with HTML. Every web page I've ever built has needed these components and while there are libraries out there, they all have an annoying bug here or there. But considering we are just now getting Select tags with styling, signals how long it might take for a typeahead which is vastly more complex.

jhardy54 1y ago
> basic typeahead It isn’t perfect, but have you tried <datalist>? Totally agree about tag pickers, I was bummed to see that Bootstrap didn’t have a tag selector component either.
- mlhpdx 1y ago
  I have, and failed. See https://news.ycombinator.com/item?id=40265782 https://news.ycombinator.com/item?id=40265782
  - recursive 1y ago
    Safari is the "new" IE. I put "new" in quotes because it's been this way for like a decade.
    - facile3232 1y ago
      If anything chrome is the engine with odd quirks you are forced to work around.
      - recursive 1y ago
        I haven't found this to be the case in my experience.
        facile3232 1y ago
        Maybe it's just iframes that are the issue but they were a devil and a half to get working in chrome (or blink ig) without relying on third party cookies.
        progmetaldev 1y ago
        Interested in what you are doing with the iframes. Something with complex authentication? I've been forced to use iframes a few times for 3rd party resources that should have been first-party (mostly with banks and credit unions), and have only had some styling issues on mobile (which have been overcome by using JavaScript and window.matchMedia to check for media queries).
      - immibis 1y ago
        Chrome's quirks become the standard and other browsers have to implement them.
    - troupo 1y ago
      --- start quote --- Back fifteen years ago IE held back the web because web developers had to cater to its outdated technology stack. “Best viewed with IE” and all that. But do you ever see a “Best viewed with Safari” notice? No, you don’t. Another browser takes that special place in web developers’ hearts and minds. --- end quote --- https://www.quirksmode.org/blog/archives/2021/08/breaking_the_we.html https://www.quirksmode.org/blog/archives/2021/08/breaking_th...
      - recursive 1y ago
        Yes, Safari is not exactly like IE because IE had a dominant user share once upon a time. We don't see "best viewed in Safari", but we do see plenty of sites that can be viewed in Safari, despite the extra effort used to get them there. And I'm not even a regular chrome user.
        troupo 1y ago
        The absolute vast majority of web sites require no effort to "get there". The absolute vast majority of those which don't work in Safari use Chrome-only non-standards. And there is a tiny minority of sites that run into some Safari-specific quirks
  - deleted 1y ago
    [deleted]
  - ricenews 1y ago
    It may not be present in Apple’s official documentation but it has been supported since Safari 12.2. See https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da... compatibility. The demo on that page works for me in current Safari on both iOS and Mac.
    - no_wizard 1y ago
      Some examples seem to work better than others though. I’m on latest iOS and sometimes it will invoke the native date picker like you’d expect to see, sometimes it won’t, and the type ahead doesn’t seem to work consistently
    - mlhpdx 1y ago
      That demo shows the problems splendidly. It “only kinda” works on iOS.
asddubs 1y ago
also drag and drop rearrange
cosmic_cheese 1y ago
Why implement broadly useful HTML widgets when you can instead put those engineering resources to work on a new WebBeer API that fetches the number of beers in the user’s fridge or something else similarly niche?

renerick 1y ago

> have options drop downs that extend outside the viewport boundaries Unless this is about something different from what you mean, unfortunately, it's not the case, as stated in the article: > Using base-select loses a number of features and behaviors: > The <select> doesn't render outside the browser pane.

asddubs 1y ago

I doubt it'll still be able to do those things. From the article: >Using base-select loses a number of features and behaviors: > The <select> doesn't render outside the browser pane. > It doesn't trigger built-in mobile operating system components. I have mixed feelings about it. Mobile users, get ready for poorly optimized select elements. On the other hand it reduces the need for javascript for styling forms, which is good

wolframhempel 1y ago
That's fair, but I assume that is the initial implementation. Surely, over time, browser vendors will want to make the full spectrum of select functionality available consistently.
- caesil 1y ago
  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.
  - immibis 1y ago
    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.
    - afiori 1y ago
      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
- dbbk 1y ago

preisschild 1y ago

<input type="datetime-local"> with automatic ISO8601 timezone offsets would be awesome too!

sublinear 1y ago
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.
- progmetaldev 1y ago
  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 convert everything to UTC in the database, and when I retrieve the data, I use it to convert UTC back to their local date/time. I felt that it was the best option, since a user moving to a different timezone should still be able to get dates/times back relative to where they have their current timezone set.
  - mason55 1y ago
    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.
    - progmetaldev 1y ago
      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).

kkarpkkarp 1y ago

> Now, do autocompletes This is kind of ready, see datalist element. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...

porridgeraisin 1y ago
I know about datalist, but it's the saddest autocomplete experience you can offer. If something is not fully styleable, it's automatically garbage. If it's styleable, it may be decent. Now, I understand why datalist is not styleable the way it is implemented right now. On Android, the suggestions come on the top bar of the native keyboard, so it doesn't make sense to be able to put arbitrary divs there. But in that case, there should be an alternative styleable autocomplete element. Another element that is unstyleable crap is <input type=file>, <audio> too.

blatantly 1y ago

Ooh I can render arbitrary pixels outside the viewpoint. Like a system dialog asking for a password.