The challenge till this is widely supported (caniuse.com currently pegs it at 46% globally [1]) will be using this as a progressive enhancement that does not provide a worse or unusable experience for users with browsers not supporting it yet.
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...
I agree that this is a huge improvement, but it's also over a decade late IMO. This should've been accomplished well before now, especially given that the issue has been there since the beginning.
Because frontend is frontend, Javascript frameworks dominated the conversation even for silly things like basic web forms for the past 15 years. Basic HTML/CSS is now catching up to the fact that not everyone wants to run a Javascript monstrosity for custom styling on very basic tasks.
The prevalence of JS and JS backed components is due to the reluctance of browser vendors to introduce new HTML elements that everyone has been lobbying for in the same time period.
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
> 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>
There's some quirks with the API around open vs openModal if you aren't aware of the accessibility implications you may not even realize this is the case.
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.
> 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:
I'm with you... would be nice to have:
<button type="open-dialog" target="dialogId">Open Dialog</button>
...
<dialog id="dialogId">
<button type="close-dialog">Close Dialog</button>
</dialog>
> I'm with you... would be nice to have:
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.
The point was to be able to do it without JS.
I understand, but from a pragmatic viewpoint, it is no more and no less complicated to do it with `onclick` JS than it would be to do it with some other attribute.
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.
If you need to worry about ADA compliance (I always do, but not always paid to), this can be difficult to address.
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.
You can't make enough HTML elements to make everyone happy. This was the wrong idea from the start.
The solution isn't to make a new html element for each use case.
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 is to make html elements extensible.
The solution would be to make Apple ship this:
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
I would argue you can make enough HTML elements to make enough people happy. 80% for the 80%.
Forms are hard because they are the most stateful and most ubiquitous UI component that everyone comes in contact with. HTML has a few barebones tools to help you out, but they aren't good enough for the best user experience if you really wanted to polish a form like show errors exactly when you want to show them and only allow submission exactly when you want to allow it and represent error states in much better ways.
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.
Over TWO decades late.
It is crazy to think what we only just have in anything non JavaScript in the past 20 years.
It's like how border-radius was added after rounded corners via images fell out of fashion.
I somehow feel Safari drags its feet on basic things platform improvements because they want to focus on iOS apps instead.
The narrative Safari is behind and Apple doesn’t care about the web is so tired…
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...
The pace of improvement in the web is slow.
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.
Eh; the standard is two weeks old. Written by someone working for Apple by the way.
I’m wondering where in my comment it sounded like I wanted this standard specially to be implemented yesterday?
This is true, and I try not to get eager about new browser improvements for this reason. But look at the porgress over time in browser abilities, it's astounding.
The days are long but the years are short.
The perpetual 5 year problem of web development. I wish there was a way to do forward standards
> But such is always a good practice anyway.
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.
You'll probably still keep a <div>-based control in your page, and selectively hide the <select> based one or this one, or generate different HTML for different browsers if you can do that.
This might be a bad take, but I think developers should also consider exactly which users are using their app. If it’s the entire internet, then absolutely you need to consider backwards compatibility. If it’s an internal app, then consider not caring and using new APIs.