The <select> element can now be customized with CSS

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>

My personal bugbear is the date/time input - FF doesn't even show a click element for time, you have to type in the time.

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.

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>

It would just make so much sense.

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

I think the problem here is that it is impossible to actually use the result from `close()`, as it can return a status, IIRC.

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