The <select> element can now be customized with CSS
developer.chrome.com
developer.chrome.com
Now, do autocompletes and tag selectors next...
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.
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
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.
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.
>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
select, option {
background: red;
font-family: 'comic sans ms';
}Actually I am now curious of how much detail/size/colours/animations you can fit in a single letter.
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)
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".
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.)
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
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.
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...
The days are long but the years are short.
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.
<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.
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:
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.
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.
It is crazy to think what we only just have in anything non JavaScript in the past 20 years.
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.
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 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.
"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.
Jack of all trades, master of none. The mspaint-specific palette toolbar was much more intuitive.
The user can still obviously see the sidebar and knows its a sidebar, it just works better with the design.
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.
(If you want to annoy your users, that's your prerogative)
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.
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.
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)
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)
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/
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.
Y'know, like how most software development works.
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.
Have you noticed how every AI interface needs to let you choose between models? The current select element is embarrassingly inadequate when you need to show more than just text labels. You want to display model capabilities, performance indicators, context sizes - not just "GPT-4" vs "Claude 3.7" as plain text.
There was one thing that I hoped would work, but didn't, which is applying an :after pseudo-class to <option>, so something like this:
option:after {
content: ' (' attr(data-descr) ')';
}
<select>
<option data-descr="some description">Foo</option>
<option data-descr="some other stuff">Bar</option>
</select>
There's another way to try it though...
I'd try putting two separate <span>s inside each option, one for the short description and one for the long description.
I'd hide one span with css if it was inside an <option> tag.
I'd hide the other span if it was inside a <selectedoption> tag.
That would probably work.
The papercut would be that when gracefully degrading back to an ordinary select element, it might show both the short and the long selections which depending on how you write the content may or may not be an issue.
The problem is that you can't target the span in the original parser.
But, you could use a template, since it's contents are ignored by text content parsers.
You can have your option as:
<option value="red"> <span>Normal Difficulty</span> <template>- The way it's meant to be played</template> </option>
With the original parser, this will be parsed as:
<option value="red">Normal Difficulty</option>
And with the new parser (so long as you opt into it with the `appearance: base-select` rule):
<option value="red"> <span>Normal Difficulty</span> <template>- The way it's meant to be played</template> </option>
---------------------------
Then once you've opted into the new parser, you can target both the span and template to render how you want. (e.g. Give span a larger font-weight, give template a display mode of block and italicised text)
I assumed your comment was trying to give the parent commenter a strategy that would work with the "classic" select but I see now that you mentioned "selectedoption" so you were talking about the new one.
If you're interested, I wrote a bit more about it here: https://harrisonbroadbent.com/blog/cool-native-html-elements...
Styleable XOR Unusable = 1.
Should be able to style more than just selects, after all. Why the fuck can't I change the mask character in a password field to be something other than bullets? Hah. I had better examples too, but it looks like in the past 10 years or so, they've slowly been CSS-ized. Nice. Now if I could just style half the first line (first-line does the entirety of the line or nothing).
Sounds like you can create loops. If the select had a style element that turns this off again would it keep changing state?
I have said it before, everyone (Developers that use Chrome almost exclusively) says Safari is the new IE but Chrome has been slowing becoming the thing they fought against since they defeated IE.
Easy on the battery, freaking fast, low ram usage, and plugin support (ALSO on iOS, yes, uBlock on iOS). Screw firefox, screw chrome.
Yes, I also dev on Orion. The dev tools are fine.
If I go to Facebook and login in one tab, then open a second tab and go Facebook, it doesn't recognize that I have logged in. There's moments where that is annoying but most of the time it's useful.
Since then my faith in Web technologies for building UI for most apps keeps increasing.
Through pure evolution - it's the most beautiful and open platform that's most cross platform.
This web API scope creep makes it __harder__ to create and maintain truly independent web browsers.. you have to implement more and more and eventually we arrive at the current state of matters - all non-chromium engines are lagging behind.
Developers will happily use this, then users will notice websites "look better" in chrome and firefox will become even less relevant. Don't.. you can already achieve this without relying on chromium-only APIs.
No; Firefox can easily afford financially to add this feature. Firefox is already irrelevant; no developer will shed a tear about just blocking Firefox if they refuse to implement. Boycotting won't work either, because boycotts almost never work.
Did I miss anything?
It’s still not as clumsy and resource intensive (while destroying hardware like disks) like Chrome..
This saddens me, as a Firefox user, but we have Mozilla's inept management to blame for this.
https://support.mozilla.org/en-US/kb/privacy-preserving-attr...
"Privacy preserving attribution" sounds like "money preserving robbery" (or money preserving tax).