Posted by tosh 4 days ago
Now, do autocompletes and tag selectors next...
>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
To me, this is intrinsically what makes a <select> a <select>. Styling is great, but without these features, this doesn't really bring anything new to the table
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".
That would require rendering arbitrary HTML in the native widget, outside the browser. And I think that would require putting WebKit in the native widget. Or, to maintain a "copy" of the widget that looks like the native one but uses WebKit to render things. Seems annoying to maintain.
(And there are the security concerns mentioned by the other comments)
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.)
Actually I am now curious of how much detail/size/colours/animations you can fit in a single letter.
select, option {
background: red;
font-family: 'comic sans ms';
}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.
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.
See 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.
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_th...
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.
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
This is kind of ready, see datalist element.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...
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.
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.
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.
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.
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).
https://caniuse.com/mdn-javascript_builtins_intl_datetimefor...
or appending the `Date().getTimezoneOffset();` to receive a ISO8601 timezone offset
In other words, don’t include critical information or functionality in the new styling that isn’t available in the underlying plain select element! But such is always a good practice anyway.
Very nice to see this taking shape though! Should be a huge improvement over the div monster that custom select box replacements often are. :)
[1] https://caniuse.com/mdn-css_properties_appearance_base-selec...
By and large browser vendors for the longest time, even today still in many respects, repeatedly ignore pleas for more elements that cover common use cases.
Even when they do arrive, they can be half baked - like dialog or details / summary - and that doesn’t help matters
How are those half-baked? No smooth transition for details/summary, maybe?
Dialog seems to work well enough with little to no javascript required:
<dialog>
<h3>Warning:</h3>
...
<button onclick='this.closest("dialog").close()'>Dismiss</button>
</dialog>
Forms have some special quirks inside of a dialog.
The biggest thing though, is for the life of me I don't understand why you can't open and close a dialog without JavaScript. There's no way to do it.
You can use popovers like this without JavaScript:
<button popovertarget="some-element" popovertargetaction="show">Open</button>
<div id="some-element" popover="auto">
<button popovertarget="some-element" popovertargetaction="hide">Close</button>
</div>
I don’t think there’s any way at present to open a `<dialog>` element specifically without JavaScript, but command/commandfor handles this and was recently added to the HTML specification:
<button type="open-dialog" target="dialogId">Open Dialog</button>
...
<dialog id="dialogId">
<button type="close-dialog">Close Dialog</button>
</dialog>
You can do this right now already:
// For opening
<button onclick='document.querySelector("#dialogId").showModal()'>Open</button>
// For closing
<button onclick='this.closest("dialog").close()'>Close</button>
> It would just make so much sense.
That way above that I propose is about as sensible as the way you propose. If there are any problems with my proposal that are solved by your proposal, I'd love to hear it.
For all practical purposes, there is no difference between the two.
I understand that the `onclick` wouldn't fire in browsers where JS is turned off, but in that case (no JS) you're going to have an awful user experience using dialogs even with builtin open/close attributes for dialogs.
I remember Opera, before it was bought, had the best support for html5 elements and date/time inputs were the best (along with almost all others). Sad to think that a leader in this area was sold off, and not to a buyer that cared about usability and the web the way Opera did.
The solution is to make html elements extensible.
With the `appearance: base-select` css rule, we now have a standardized way to extend <select> with html and css, (and we have the potential to declaratively extend intractability too with invoking commands without needing to reach for JS)
The solution would be to make Apple ship this:
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
It's especially obvious once you're making forms outside of HTML and you realize that it's not any simpler with any less UX consideration. The only thing that changed was the language you're writing that polish in.
It is crazy to think what we only just have in anything non JavaScript in the past 20 years.
This 8,000+ word article on Safari 18.4 (released today, BTW) doesn’t read like an organization that doesn’t care about the web [1].
[1]: https://webkit.org/blog/16574/webkit-features-in-safari-18-4...
I don’t want to debate if a mega corp cares or not, but compared to how UI frameworks were in the 90s, the developer experience is anemic.
I don’t know if HTML, CSS and JavaScript are the best path forward. Maybe they are doing exactly what their spec set out to do.
But we need something better that doesn’t leash one to an ecosystem that takes 30% of your revenue.
The days are long but the years are short.
One more reminder to develop for people who may not perceive color and shape as you do. If you're hiding critical information in your menu styles, that information is presumably inaccessible to people who are using a screen reader.
I worry about this. The built-in mobile operating system components are reliable, accessible, and responsive. I really like it when an input element opens the Android UI because I know how it works and that it is reliable. This applies to <select>, but also date/time inputs for example.
This is then won't be consistent with native OS apps, but still be consistent across websites. Better than everybody doing different div+JavaScript magic which behaves slightly different across different websites.
And it doesn't get the job done. You can't put stuff like SVGs or complex DOM elements in them, which is a valid use case. Most of the time, when people create custom select boxes, they ignore accessibility. This will fix that issue.
The user can still obviously see the sidebar and knows its a sidebar, it just works better with the design.
Limiting information can be harmful in many cases, and make things more difficult rather than simpler. And consistency can similarly limit usability.
What if I want to select one of 10 colors, with limited screen space? Isn't a select with color swatches perfect? Or even better, color swatches with color names beside? Why do you think that should be limited to plaintext only? That's anti-user.
"I want things to be worse" is not a compelling argument. Letting developers describe the needs of their applications with a consistent grammar is not unnecessary invention, complexity, or friction.
The grammars of a technology, the set of building blocks with which developers are empowered to create, should balance flexibility with expressive intent. CSS <select> strikes this balance nicely. To decry its inclusion says more about the naysayer than the feature.
I don't want to have to click each green to see the swatch. Just put them in a list with swatches. That is obviously the easier UX. Nobody has to stop and think about anything.
Jack of all trades, master of none. The mspaint-specific palette toolbar was much more intuitive.
What's worse are the custom JS ones that only appear on hover, obscuring the contents partially where they happen to be, and then when you try to drag them and accidentally move the pointer just a tiny bit off their skinny width, they disappear and you end up accidentally activating whatever element happens to be underneath.
(If you want to annoy your users, that's your prerogative)
I don't have Chrome installed, but I'm curious how it handles multi-select fields, as I didn't see that in the example video.
Also just tried it with multiple="multiple" just in case. Same behavior.
Y'know, like how most software development works.
I am not holding my breath for a decent "select multiple" field. It's been the same crap for decades and browsers could have fixed it long again without waiting for spec - it's just a "replaced element", but they don't care.
The fun part is that it looks amazing on Safari iOS (and QED it's rendered as a list of checkboxes)
Search textbox: would be supported under the more customizable Combobox element
Select Multiple: both the Enhanced Select and Combobox plan to support this
Combobox: https://open-ui.org/components/combobox.explainer/
Enhanced Select: https://open-ui.org/components/customizableselect/
Not necessarily. I've seen more than one production app with a custom filtering dropdown list of items with checkboxes.
I built a couple variants of that in React at my last gig for the company's design system. The keyboard nav was complex... that component is one of the work artifacts that I'm most proud of.
I already said that. "Select" is not filterable in the browser already, so `select[multiple]` has no chance of seeing that in this decade.
However you slice/style it, it's just checkboxes (that you can filter/reorder)
Why release anything right?
They didn't mention it in the blog post that multiple isn't supported. Its perfectly fine if it is not supported right now. It would be great if they acknowledged that up front to set expectations accordingly.
For instance, if its explicitly not supported, then I won't be left wondering if its a bug or a misunderstanding of the implementation etc.
Communication would be really good here. I'm all for incremental improvement, I think we need more of it.
Doesn't mean there shouldn't be better communication about it.
https://developer.chrome.com/blog/rfc-customizable-select
> Note: The multiple and size attributes on select (<select multiple> and <select size=n>) are not supported in appearance: base-select yet.
and now this as of Chrome 135 is shipped, and they didn't think it wise to include a back reference to this post, calling out what isn't supported?
They can and should communicate this is all.
Count me in. Most times it didn't matter to me but there were some cases when I wanted or needed them to have a specific style matching other elements and, yes, I could only do it -to the best I knew- with JS.
Let's see if it becomes widely supported.
We're only waiting on Safari now: https://github.com/WebKit/standards-positions/issues/386
Last update to the issue is a pointer to test results:
https://wpt.fyi/results/html/semantics/forms/the-select-elem...
At least Safari is failing as well, currently, so the FF team has a bit of time.
> It doesn't trigger built-in mobile operating system components.
Yeah so this is scary, but how is layouting done then?
> Shown options positioned with anchor().
Ok, also experimental, but maybe this is the best part of all? Floating UI? It’s become a reusable thing with JS, it would be amazing if it was in CSS and actually worked.
>Yeah so this is scary, but how is layouting done then?
Via HTML in-website, not via opening the android wheel picker or anything like that.