7 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...

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.
- 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?
- 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...
- asddubs 1y ago
  also drag and drop rearrange
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
- kmeisthax 1y ago
  For the record, there's already a bunch of custom select-a-like replacement elements out there; I'm partial to select2. The main reason for this is that selects don't come with what we used to call "combobox" features; there's no type-ahead completion, and you can't lazy-load options from a larger data source because of that. My main gripe is the loss of rendering outside the browser pane. To be clear, we already don't have that on mobile at all; if you've ever used an iPad with Stage Manager you'll note how popovers - all of them, including native apps - are neatly conformed to the bounds of the containing window. Pop-over menus are supposed to break the window pane, but they don't, for reasons I don't quite understand but can guess rhyme with the word "security".
- immibis 1y ago
  Mobile users are the majority of users by far. Do web designers really make their sites hostile to most of their users? (I suspect the answer is yes)
  - qiqitori 1y ago
    I think this totally depends on the site in question. Seriously researching something is hell on mobile browsers. As is doing productive stuff. Who wants to work on a tiny screen and no keyboard? On the desktop you can open dozens or hundreds of tabs on a single topic. Therefore I'm not surprised to see that on my site (technical articles) I can see the number of requests from mobile devices is just 17%. Windows is 52%, Linux (without Android) is 18%, Macintosh is 13%, Android 11%, iOS 6%, Chrome OS 0.5%, others <0.5%. (Android and iOS may include tablets, but the overall traffic from tablets is just a few percent.) (Note that I've excluded crawlers and unknown user agents (bots and crawlers) from these results.) FWIW, some bots lie about what they are, which typically inflates the Windows results. I have another source of data, I can see what types of devices saw my site in Google results, and it's 69% desktops, 30% mobile, 1% tablets. (I can also see how many clicked, and it's similar numbers.)
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.

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?
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...
asddubs 1y ago
also drag and drop rearrange

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

kmeisthax 1y ago
For the record, there's already a bunch of custom select-a-like replacement elements out there; I'm partial to select2. The main reason for this is that selects don't come with what we used to call "combobox" features; there's no type-ahead completion, and you can't lazy-load options from a larger data source because of that. My main gripe is the loss of rendering outside the browser pane. To be clear, we already don't have that on mobile at all; if you've ever used an iPad with Stage Manager you'll note how popovers - all of them, including native apps - are neatly conformed to the bounds of the containing window. Pop-over menus are supposed to break the window pane, but they don't, for reasons I don't quite understand but can guess rhyme with the word "security".
immibis 1y ago
Mobile users are the majority of users by far. Do web designers really make their sites hostile to most of their users? (I suspect the answer is yes)
- qiqitori 1y ago
  I think this totally depends on the site in question. Seriously researching something is hell on mobile browsers. As is doing productive stuff. Who wants to work on a tiny screen and no keyboard? On the desktop you can open dozens or hundreds of tabs on a single topic. Therefore I'm not surprised to see that on my site (technical articles) I can see the number of requests from mobile devices is just 17%. Windows is 52%, Linux (without Android) is 18%, Macintosh is 13%, Android 11%, iOS 6%, Chrome OS 0.5%, others <0.5%. (Android and iOS may include tablets, but the overall traffic from tablets is just a few percent.) (Note that I've excluded crawlers and unknown user agents (bots and crawlers) from these results.) FWIW, some bots lie about what they are, which typically inflates the Windows results. I have another source of data, I can see what types of devices saw my site in Google results, and it's 69% desktops, 30% mobile, 1% tablets. (I can also see how many clicked, and it's similar numbers.)

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.