Customisable select I believe is the first to come out of it.

https://developer.chrome.com/blog/rfc-customizable-select

https://github.com/whatwg/html/issues/9799

The first ones are Exclusive Accordion, Invoker Commmands, Popover. See graduated proposals at https://open-ui.org/

Customizable selects will be the first that adds a new element, rather than new attribute behaviors or new attributes. Those have still been significant, of course.

Hopefully the user has the same freedoms to style things how they would like.

Yes, one can style them with a userstyle as always.

Most browsers let you extend a page’s css (at least via extensions)

I don’t think this would be immune to that.

Until Google realizes you're using the capability to hide advertising and disables the feature to create a "trusted client" (trusted by Google to render their ads faithfully). They've pitched the idea before as a way to force users into Chrome from the server-side.

I'll go back to shouting at clouds now... Sorry.

Some pages seem to randomize element IDs to prevent adblockers from doing their job; randomizing CSS class names wouldn't be out of the ordinary.

if anything a standard element is easier to style on your end than everyone using a custom one right?

Not really, because for a native element you're dependent of their APIs. For example the color picker will only use the system color picker, a lot of other native elements are hard to style. So custom elements are often easier to style but harder to maintain and usually bad for accessibility.

"styling on your end" means the _user_ (not the website designer/developer) deciding how controls should be styled and that's much easier if everything uses the same controls because you only need to specify it once and don't need a library to hook all possible UI frameworks that exist.

Users deciding how input controls are styled? Who exactly asked for THAT?

Heard of userstyles?

We have <input> and <label for=""> elements, but what about <validation for="" condition="" message=""> elements?

Condition could be a wide range of possible built-in validation functions or a custom regex or js function.

Instead of adding all these validation attributes to <input> elements you could have zero or more <validation> elements, each with their own message.

The message could automatically appear when its conditions fail. Unless you call preventDefault() inside an "invalid" event handler. The invalid event could have a list of all "validations" for that element and you could check their status via js, disarm/ignore them individually, or get their messages etc.

Don't we already have that basically, with HTML5 form validation[1]? Often just using the pattern attribute is enough to make sure you don't get a phone number in your email field etc.

1: https://developer.mozilla.org/en-US/docs/Learn_web_developme...

Yes, but it's user agent UI which is not really good in any of them.

Good error messaging is important and having styleable semantic elements would be helpful. It's tricky because you often need more than one error message per input, not just "required" but too big, too small, wrong format, etc.

Right. You can use browser validation and extract the error messages with JavaScript (to style them yourself, e.g. [1]), but there’s no solution without JS yet.

[1]: https://github.com/notpushkin/evilmartians-exercise-auth/blo...