So after decades of developer pain, all we're getting is a better select?
Where is the native HTML datagrid (that supports sorting, filtering, paging, downloading, row/column freezing, column resizing and re-ordering)?
Where are the native HTML Tabs control? Image selector, resizer/cropper, and uploader? Toggle button? etc.
We can't even get text input to respect autocomplete directives properly. On the major browsers, giving your user id and password inputs nonsensical names seems to be required, along with numerous other hacks, to ensure that when a user is registering, the form is not auto-completed with saved passwords.
Progress is very gradual in this space, but browser vendors are working on a lot of this stuff in the Open UI W3C community group. https://open-ui.org/
You implement tabs today (aka accordions) with `<details name="tab">`. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de... "This attribute enables multiple `<details>` elements to be connected, with only one open at a time. This allows developers to easily create UI features such as accordions without scripting."
You do have to write some CSS to align tabs horizontally, but it's fine.
> Image selector?
Use `<input type="file" id="avatar" name="avatar" accept="image/png, image/jpeg" />`. Opens the OS photo picker on mobile. You can style it however you like.
> We can't even get text input to respect autocomplete directives properly.
"Properly" seems to be doing a lot of work there. "autocomplete" works fine, but it's annoying to get it right, and this kinda can't be fixed, because HTML is under a lot of backwards-compatibility constraints.
If you have autocomplete bugs to file, file them, and maybe convince the Interop group to focus on this issue. Their priorities for 2025 were just announced, but there's always next year. https://web.dev/blog/interop-2025
> it's annoying to get it right, and this kinda can't be fixed, because HTML is under a lot of backwards-compatibility constraints
Sorry, but this seems like a wild mischaracterisation, at least in regards to the problems I've had with users on Chrome. In our experience, Chrome aggressively shows an autofill prompt on almost every input it can. It also ignores the specced autocomplete=off attribute. We have observed Chrome showing a password prompt on an <input type=number> which is just bonkers. It is not hard NOT to do this.
The Chrome team thinks whatever heuristic they're using is better than allowing developers, or even end users, to control filling behaviour.
(By "autofill" I don't necessarily mean the input is automatically filled without user interaction, but sometimes a promotions shown with e.g. account login details or an address.)
The argument has been that developers are naughty and turn off autocomplete inappropriately, which worsenes accessibility. But I've never seen e.g. a tooltip option in a browser to let me, the user, fill in details when I know they're appropriate? I am merely at the whim of the Chrome algorithm.
Problem with autocomplete=off is some morons think they should use it on their login form for "security" or whatever, cause forcing users to type in passwords is "secure". So browsers wound up having to ignore it for actual security.
Browsers could have instead allowed me to right click and say "insert password because I know what I'm doing". But browsers are in the business of training users to be stupid, rather than acting as a user's loyal agent, so I guess we were mercifully spared this future.
I am one of those morons who had to build a page for someone to go to the nurse's office and input all their information without it being saved for the next person who goes there to fill their information.
Problem is we (my development team) didn't own the tablets, some other team did so we couldn't force the tablets to have in private browsing.
Yes, disabling autocomplete can be annoying, but it is possible. Usually it amounts to being more descriptive in the value of the `autocomplete` attribute, rather than simply applying `autocomplete=off`.
> We have observed Chrome showing a password prompt on an <input type=number> which is just bonkers.
"We have observed" it, but not filed a bug? Neither of the bugs you linked to exhibit that bug.
> Usually it amounts to being more descriptive in the value of the `autocomplete` attribute
No, there are many inputs where there is no sensible autocomplete value. For example, "create a new CRM customer record". This is a new customer who I have not seen before. By definition it is impossible to autocomplete.
In the past, the Chrome team advised to "make up an autocomplete value and we won't do anything with it". This advice is a) dumb and b) no longer works anyway.
> but not filed a bug?
It's clear the Chrome team has no interest in fixing this behaviour so I'm not going to waste my time. Yes, that's bad of me, but I have bills to pay.
If you're a Chromium contributor or otherwise involved, I'd be happy to chat further about this and work up a submission to demonstrate the issue with a minimal repro. But if not, I don't think they need you to stick up for them.
It's clear from the threads I did post that lots of devs are frustrated with Chrome's behaviour and the team's lack of attention to not just fixing bad behaviour, but complying with the HTML spec. Without even focusing on the type=number problem, I have spent enough time fighting other behaviour which is only an issue in Chrome.
> you only vaguely remember a bug
Thanks to that ad-hom I am now irritated, and I went back to our internal Slack to find the screenshot of the type=number bug. Sharing a screenshot here would have no real value to this discussion, but it's real.
A cursory search would show you how much frustration there is around broken autofill attributes. Such a dismissive attitude helps no one. Would you like me to paste the contents of the Jira issue I did last month working around a password input where we couldn't turn off autofill?
> Use `<input type="file" id="avatar" name="avatar" accept="image/png, image/jpeg" />`. Opens the OS photo picker on mobile. You can style it however you like.
This just selects the image. 99 times out 100, you want to do the same things with the image data: adjust it in some way, and save it to object storage or something. The file input is too primitive for this. And this is the theme all over, HTML control remain too primitive to do any real world rih UI with, which leads to the proliferation of JS UI libraries.
> If you have autocomplete bugs to file, file them, and maybe convince the Interop group to focus on this issue. Their priorities for 2025 were just announced, but there's always next year. https://web.dev/blog/interop-2025
Autocomplete "bugs" abound aplenty, some of which will make your jaw drop. I've been testing with Chrome and Firefox. The length to which browsers will go in a misguided attempt to be clever with auto-complete is frankly absurd. So I'm not sure they are "bugs" so much as they are a wilful refusal by browser vendors to follow the spec.
No, there's just the one "bug": browsers ignore autocomplete=off.
And, as you say, the browsers regard that not to be a bug, because when they honor developers request to prevent autocomplete, users keep filing bugs on the browsers, saying "why won't you autocomplete this??"
Put something descriptive in the autocomplete, instead of "off", and you're usually fine.
An image cropper didn't make the list. Data table did! But it's pretty complicated, and, as I said, progress is slow. Partly that's for backwards compatibility reasons, and partly it's because you have to get Apple, Google, Microsoft, and Mozilla to all agree on anything, and that's really hard.
Autocomplete is on the list of pain points. But it's wayyy further down the list than having a customizable `<select>`. Styling & customization, validation, and `<input type=date>` are all bigger pain points than autocomplete.
You sound like you are not ready to face reality. I put it to you that I have observed _numerous_ deviations from the autocomplete spec that defy all logic.
If you want a laundry list of them, I'm ready to list them all in their gory details here, but I suspect you have made up your mind irrespective of the facts.
> 99 times out 100, you want to do the same things with the image data: adjust it in some way, and save it to object storage or something.
That's kind of a bonkers expectation for the browser to fill. It's like expecting that <input type="audio" /> should let me crop the audio and add reverb to it. That's two specific manipulations out of untold thousands, and squarely within the purview of a different app. https://editor.audio/ (never used this, just an example)
> This just selects the image. 99 times out 100, you want to do the same things with the image data: adjust it in some way, and save it to object storage or something. The file input is too primitive for this.
That's not true at all. Obviously there's no `adjustinsomeway` or `savetoobjectstorage` attribute on the <input> element, but you can trivially grab the selected files, read them, and act on them with JavaScript: https://developer.mozilla.org/en-US/docs/Web/API/File_API/Us...
Why not something similar to what iOS has? Or Windows?
They all have functional built in image editors. They're very light weight, and are not meant to replace a dedicated tool, but if all you want to do is crop an image or other relatively simple tasks, there's ample evidence on other platforms that providing these minimal tools is big value to users.
> This just selects the image. 99 times out 100, you want to do the same things with the image data: adjust it in some way, and save it to object storage or something.
This is probably the reason why someone invented the <canvas> element?
Datagrid is mysteriously missing on several newer desktop UI frameworks too, which effectively makes those frameworks ill-suited for a whole range of desktop applications. The only place reasonably batteries-included versions of those widgets can be found are in the old guard toolkits like AppKit, win32, MFC, Qt, GTK, etc.
Which parts of a datagrid should a browser provide? I'm familiar with AG Grid [1] and the API surface is enormous. Aligning browsers on a feature set would be challenging.
The simplest would be to follow the aria role=“grid” spec, ideally with sortable columns. IMO it doesn’t need the kitchen sink AG Grid approach just a sane way to semantically build a data grid with proper accessibility.
It has to handle every possible use case for a grid. You’re thinking of your use case. The spec needs to handle everything else. I don’t see how that’s manageable.
A good spec really only needs clear principles. At a minimum, it should clearly explain what it does do, and also clearly explain what it does not do.
You don't need to have every edge case covered to build an API for datagrids. iOS has had native DataGrids for ages, Windows, macOS, Android. They all have this stuff built in. Other platforms have figured out how to provide these API surfaces.
Why does the web have to be seen as a special unicorn that can't have good baseline components like these platforms?
Are any of the examples you gave an open standard with multiple implementations from different companies? If Apple gets their implementation wrong, they can always deprecate an API and move forward. If they want to throw out an old implementation and deprecate that completely and start over, they can do that. The Web standard depends on agreement by multiple large organizations. That level of communication slows everything down. If they get an API wrong, we’re stuck with it forever.
That’s why the web is a special unicorn. It’s very different than those platforms. Web standards should be small and composable. They shouldn’t try to solve every problem. I get why you would want a data grid. Maybe in your work it’s a common pattern. But on the broader web and in all of the documents that are out there, it’s on a minute fraction of them. It’s simply not worth the effort. Too much effort, too little gain.
>Are any of the examples you gave an open standard with multiple implementations from different companies?
ECMAScript / JavaScript. It has evolved at a faster pace since the introduction of ES6, and we been getting new features every year for awhile now. Given the types of features they're willing to ship with the languag and that many of the same people working on the HTML spec work on ECMAScript, it seems 'niche' isn't an issue (simply look at how many features have been added specifically only for classes vs the amount that the language construct of class is actually used. Its tiny in usage, but they've added alot of class specific features)
Other notable examples include the C and C++ standards (there are differing vendor implementations depending on platform which while annoying are largely well known how to navigate). Linux operating systems - the amount of incompatibility between linux distros is shockingly small all things considered.
I'm sure there are others I'm not able to think of as well, but this isn't special to the web by any means.
At minimum filtering and sorting should be handled by the browser, including async for both of those.
Pagination could be argued as well, but at least that's simple-ish to implement (but still, it's such a common UI pattern that it ought to be handled in a unified way by browsers IMO)
Look at how much effort has gone into just getting a stylable select box. Look at tooltips. A data grid is several orders of magnitude higher in complexity than both of these. You are severely underestimating the complexity of your ask. HTML/JS/CSS is not supposed to solve all your UX problems. It’s a toolkit for building UIs, not a framework.
Is it not the design by committee approach that slows down the design consensus on things like these? Just complex is it to design a spec for a stylable select box that is reasonable for most use cases?
If it has to take decades to agree on a design for a stylable select box, then there is something fundamentally broken with the approach.
For an open standard, how do you design it without agreement among a committee? Just let Google go rogue and define it? And have you ever worked in a large company? Have you seen how difficult it is to get any large group of people to agree on ANYTHING? These specs depend on the agreement of multiple large companies coming together. Each one of those companies is made up of many subcommittees who have to come into agreement with each other.
While maybe you could imagine a straightforward technical implementation (and I think you’re overlooking the complexity of getting the API right while making it extensible), the social engineering involved to make this happen would be Herculean. And it would be for an element that’s on less than 1% of web pages. If you really want a data grid, I’d suggest learning how to code one. It’s a fun challenge, and implementing basic features like sorting and filtering isn’t difficult using a modern framework. If it is difficult for you, then I’d suggest that it would be a GREAT experience to try. Then imagine how you’d make it extensible for unknown use cases.
The main reason it took decades for a stylable select box is because for two decades, we were just told “Don’t style select boxes. It’s bad for usability,” which was a mistake. We’ve only started to overcome that mindset in the past few years. The work on stylable select boxes only started in the past few years.
> For an open standard, how do you design it without agreement among a committee?
There's a difference between design-by-committee, and approval by committee. I'm arguing against the former. This is not to say that I have much hope that my approach will prevail, but it is an indictment of the W3C/WHATWG that they have not figured out a better process for producing technically excellent and coherent designs/specs in reasonable time.
Just invite submissions from small teams that each have produced a coherent design, and then the hard process of agreeing/voting on them will be a bit easier.
> If you really want a data grid, I’d suggest learning how to code one.
I have designed and implemented highly sophisticated data grids, and I have published related libraries on NPM. I wonder what in my comments makes you think I lack the competence or experience to implement one.
The problem is the JS bloat that we have to deal with. It is ugly that we have to load megabytes of JS to render any reasonably sophisticated web UI. Multiply that by the millions of sites that have to do that, plus all the upstream dependencies that are loaded with that, and also consider all the security/privacy issues with so much JS, and hopefully you'll begin to understand the critical need for a revamp of the HTML space.
It is actually a reaction to websites doing stupid things to try and prevent password auto-fill. The sites are fighting against security in a misguided attempt to improve security, so the browser vendors added a bunch of heuristics to try and correct these situations and you end up with the mess we have.
Equally having to jump through extra hoops to prevent autocomplete where you don't want it is frustrating, like in admin interfaces where you might be updating someone else's name.
RE autocomplete in Chrome. The only thing we've found to work reliably is ensuring that all inputs are in form elements. Any inputs outside forms are going to have inappropriate autocomplete prompts. It's extremely annoying but at least this works for now.
(I say "for now" because who knows when the Chrome team will change their heuristic?)
> Why wouldn’t you put your inputs in a form element?
Not all inputs are form-submission data.
For example a datalist-backed input to scroll to a specific page/chapter/section/subsection in a long document. You might populate the datalist with hundreds of entries so you don't have a long list of links that the user will have to scroll through in the sidebar. You can perform the scroll on the change event of the input.
That's a good UI for the user, instead of presenting a long list of links for the user to browse/search through, they simply have the input auto-suggest based on the populated datalist.
I mainly work on a large complex SPA with UX that does not often look like a form, but does have lots of inputs. These days I'm much bigger on semantic HTML, to the small extent it matters in our case, but there is a large burden of pages which were just div soup and loose inputs.
HTML can never be meaningfully improved, that fact is at the heart of the current attitudes by the browsers. We are 20 years into the takeover from the W3C and still can't even do a PUT request without JS, nevermind anything approaching even one tenth of the capability of XForms.
The best we'll get is little improvements like this which everyone will ignore because ChatGPT will recommend some react component instead.
Right? There are already dozens of deprecated elements, just deprecate these too and give us new ones that actually do what they're supposed to do and don't require us to know the entire history of HTML just to do a dang <select> that isn't ugly.
Imagine a world where instead of letting IE die, microsoft decided to add a <XLS> tag in the early 2000. The most used nocode database in the world directly in the browser. In 2000.
I think some of this stuff isn't the responsibility of HTML. If HTML already has a full autocomplete spec, isn't it the fault of browsers/extensions/OS if the implementation is broken? Or are you saying the spec is too ambiguous?
A lot of stuff becomes redundant under the framing that HTML is designed to provide semantics, not a user interface. How is a toggle button different from a checkbox? How are tabs different from <details>, where you can give multiple <details> tags the same name to ensure only one can be expanded at a time?
Image manipulation is totally out of scope for HTML. <input type="file"> has an attribute to limit the available choices by MIME type. Should there be special attributes for the "image" MIME type to enforce a specific resolution/aspect ratio? Can we expect every user agent to help you resize/crop to the restrictions? Surely, some of them will simply forbid the user from selecting the file. So of course, devs would favor the better user experience of accepting any image, and then providing a crop tool after the fact.
Data grid does seem like a weak spot for HTML, because there are no attributes to tell the user agent if a <table> should be possible to sort, filter, paginate, etc. It's definitely feasible for a user agent to support those operations without having to modify the DOM. (And yes, I think those attributes are the job of HTML, because not every table makes sense to sort/filter, such as tables where the context of the data is dependent on it being displayed in order.)
Generalized rant below:
Yes, there are pain points based on the user interfaces people want to build. But if we remember that a) HTML is a semantic language, not a UI language; and b) not every user agent is a visual Web browser with point-and-click controls, then the solution to some of these headaches becomes a lot less obvious. HTML is not built for the common denominator of UI; it's built to make the Web possible to navigate with nothing but a screen reader, a next/previous button, and a select/confirm button. If the baseline spec for the Web deviates from that goal, then we no longer have a Web that's as free and open as we like to think it is.
That may be incredibly obvious to the many Web devs (who are much more qualified than me) reading this, but it's not something any end user understands, unless they're forced to understand it through their use of assistive technology. But how about aspiring Web devs? Do they learn these important principles when looking up React tutorials to build some application? Probably not—they're going to hate "dealing with" HTML because it's not streamlined for their specific purpose. I'm not saying the commenter I'm replying to is part of that group (again, they're probably way more experienced than me), but it reminded me that I want to make these points to those who aren't educated on the subject matter.
Apple’s webkit team killed customised built-in elements by refusing to implement them on ideological grounds, so you get a dripfeed of piecemeal solutions instead.
Those reasons are not ideological and there's a new proposal that doesn't have the downsides of the original spec and enables new use cases discovered since: https://github.com/WICG/webcomponents/issues/1029
Nothing with customizable built-ins would give you what the original commenter asked for
14 years have been wasted on making web components happen, and they still offer... nothing really, and people already advise to skip large portions of their specs (Shadow DOM) even if you adopt them.
Imagine if the literally millions of dollars spent of them were spent on something like https://open-ui.org/ (started by Microsoft of all companies and now also completely overrun by Googlers)
I find web components very useful. Yes, I avoid shadow DOM as it only makes things more complicated for me, but having bits of functionality grouped in a new tag is great.
> You just take some normal HTML markup, wrap it with a custom element, and then write some JS to add capabilities which you can then style with regular CSS! Everything’s of the Light Side of the Web. No need to pierce the Vale of Shadows or whatever.
I'm not sure how those comments address the need for a built-in table element with the said features. Can you explain, or link to demo that shows what you are trying to say?
react-select does a lot more than style the select though, so even after this new standard for customizable selects is supported everywhere, react-select will still have about the same level of complexity as it does now.
I am honestly just blown away Google invested effort into a web standard that actually improves the web versus the dozens of web platform projects designed to let websites slurp more data.
This is something I actually look forward to being able to use when Firefox gets it.
There’s got to be a happy medium between using canvas to make the controls you actually want and browser-provided one-size-fits-nobody controls. I really thought MS was onto something with Silverlight’s with XAML but that died.
I think that CSS is excessive, that I often disable it and that the excessive design means that sometimes the way to fix it is to add more stuff, which just makes it more messy. (In many cases, it would be helpful to put things that only the end user controls and that document author does not control. Yet, they don't really design them for that very well.)
I've been doing front-end since the days of IE5 and I'd be rich if I had a penny for every time I've had to do a custom "select". It's a pain to use third-party libraries for this, but it _is_ a solved problem and doesn't require that much extra code.
Which libraries have solved this problem? I recently tried several of the most recommended standalone JS libraries for implementing a <select> with icons and a custom layout, but each single one of them was seriously lacking in some way.
It's not a solved problem. There are maybe two libraries out there that are customizable, performant, and don't break things like keyboard navigation and accessibility
Yeah the problem is when you need to create a custom select without using a 3rd party library, and you want to make sure the interactions are accessible and up to parity with native selects. Then you have to add tons of event handlers, aria attributes, refs for handling outside clicks, etc etc.
I spent days building this little perfect dropdown select thing, that is a hundreds lines of code and even more docs explaining what the hell is going on. Someone wasted the same amount of time before me. Someone else spent a lot of time before them. And so on.
I wish we have had more browser native implementations including some notion of virtual lists so the browser would not choke when rendering a lot of content.
---
Eventually, this would be same as border-radius. It will get implemented and we'll forget about that forever.
It's not surprising, really: web components suck for having highly-customizable inputs.
1. You get HTML attributes to pass data in, or JavaScript properties. If you're in React, you'd just use a React component and skip web components. If you're in vanilla HTML, you can't just write HTML, you have to build the component with the DOM.
2. There's no real standard to making web components look the way you want them to. You can't just use CSS (you have to have the shadow root "adopt" the styles). Your point of "make it styleable" is actually one of web components' biggest weaknesses (IMO).
3. Web components are globally registered. React/Vue/Svelte/etc. components are objects that you use. You end up with a mess of making sure you registered all of the components you want before you use them (and not registering the ones you don't use) and hope no two packages you like use the same name.
> There's no real standard to making web components look the way you want them to. You can't just use CSS (you have to have the shadow root "adopt" the styles).
Not exactly. There’s the ::part() pseudo-element selector, which allows you to target an element in the shadow tree that has a matching part attribute.
Which is honestly kind of wild. You can't, as far as I know, customize pseudoelements of the part. You can't customize them in context (no striped table rows). You kind of have to just pray that custom properties work like you hope.
Because web components themselves break even in the expected situations? And need 20+ new spec to make them work? And because they are neither low level enough nor high level enough to be useful for the use case you described?
So <some-element> is a web component that adds extra features to the input. So it constructs a shadow DOM, puts the <input> into it, styles the input appropriately, etc. And before the web component finishes loading, or if it fails, or if web components aren’t supported in some way, it still works like a normal <input>.
Same thing, right? Nope! This doesn’t work! Web components can only style their immediate children. So the first web component can style the <input> element, the second web component can style the <textarea> element, and the third web component can style the <select> element… but it can’t style the <option> element.
Web components are full of all of these random footguns.
> Web components can only style their immediate children.
This isn’t true at all. You’re doing something incorrect when creating your shadow root or adding your styles. (“Web components” aren’t really a thing - it’s a marketing term for a set of technologies - so I assume that you’re talking about custom elements with shadow roots here.)
This is an empty nitpick. The people writing the specs call them web components, the people implementing them call them web components, the people writing them call them web components. There is nothing wrong with calling them web components.
> I assume that you’re talking about custom elements with shadow roots here.
You don’t have to assume anything. I explicitly said that it constructed a shadow DOM.
Yeah, slotted elements have to be direct children, but you can select any descendant in CSS. That text is only referring to the ::slotted() pseudo-element.
- Why is picker a function like `::picker(select)`, and not a CSS pseudo class like `::before` to select the `select`'s `picker` component? I.e., `select::picker` makes a lot more sense to me.
- What about multi-choice (`multiple` attribute) `select`s?
Because it's been trendy to introduce a new unintuitive syntax with every new CSS feature.
I am genuinely afraid for the future of CSS as it is becoming increasingly more complex, meanwhile most people haven't been able to properly utilize or understand it for the last decade even without all of that additional complexity.
I don’t understand the hatred for select multiple on desktop. It’s a list box that uses standard UI conventions that have been present for three or four decades now.
They're probably referring to it not being usable without keyboard, unlike regular select, or checkboxes, or anything else sans a text field. Specifically, to select elements one by one, you need to hold down Ctrl (on Windows; modifiers for other OSes are different).
For better or worse, this element is not obvious for those who didn't grow up using desktop computers 10+ years ago.
I use it in one place in my app, and even with me putting text right above it saying something like "ctrl+click to select multiple entries", I still periodically get emails from confused users. No idea what the actual % is, but it's gotta be some non-trivial fraction of people who just have no idea how to use that thing.
The thing is, this is a catch-22 problem: if everyone used the default multiple select, people would know how to operate it (and they’d be able to transfer their knowledge from how the control works elsewhere in their os to the web: for example, if you know how to select multiple files in Finder, Windows Explorer or in a open file dialog, it works exactly the same way in the multiple select control). But, because web developers have decided to invent a 1,001 different multiple selects, the default control is inaccessible.
The real issue I have with the web is everyone has broken user interface consistency across the platform with custom web controls where the default controls would be fine.
The trouble with the multiple select is that you have to use it usually when that's what the control is. Users who don't know to control-click can do things like moving files one at a time in the OS, but rarely (never?) is an OS showing you a control like that that makes you use ctrl-click to use it at all, vs. a list of checkboxes or whatever, or contexts like selecting files where you usually can accomplish your goal piecemeal.
I agree that the feature/appearance/accessibility inconsistency you get from reimplementing the controls is a problem, but I think the right way to fix it is to raise that common floor of what the web platform provides. People want, e.g., comboboxes, they've been around forever in UI toolkits, but the web's standard answer for them is still pretty terrible, so it's no surprise that people reach for the libraries that replace the whole thing.
In fact, I remember at some point, they were trying to sell the idea of exposing all the form inputs to use the `::part` API, since under the hood form inputs share the same general logic of custom elements, If I recall correctly.
From the looks of it, didn't work out that way though.
And I think its for the best. I like this proposal more, even though delivering the `::part` API to everyone (not just web component users) would have likely been faster
Using ::part() was a bad idea. Part is for user-defined pseudo elements. The platform can just define real pseudo elements. I argued against using `::part()` in spec threads, and I haven't looked back recently, but I think that argument won over.
This is a very good start, I don't think it'll replace a lot of the custom code/comboboxes that are seen in react-land without search (unless I missed it).
The point of Chrome-only CSS (vendor-prefixed features) would be to allow Chrome or any other vendor to expose styling functionality to CSS authors in valid CSS syntax in ways that won't impede future standardization efforts (like writing non-standard CSS would do) or interfere with that same CSS being processed by other vendors.
But this article isn't an example of Chrome-only CSS, this is about a change to the standard select element to make it customizeable in a standard way. It's not fully frozen yet, so they're seeking feedback and still working on it, so if you have input to give about this feature I think they'd welcome it. This blog post was about Chrome introducing experimental support for it, likely so developers can experiment with it and provide more valuable feedback towards its standardization!
Why dont you read the article and see for yourself.
> A customizable version of the select element is officially in Stage 2 in the WHATWG, with strong cross-browser interest and a prototype for you to test out from Chrome Canary 130.
> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that".
It's absolutely not that- it's an early implementation of a drafted WHATWG standard in the "iteration" phase, put behind a development build and a development flag so people know that it isn't stable and might change and nobody who doesn't explicitly opt in will be affected. This is literally made to allow "people who try to set some standards" to test their proposed standards and iterate on them before finalizing the proposal.
As far as accessibility, the native browser select is almost always going to be more accessible than someone making a custom input using JavaScript so they can add some styling control. Having the native version support basic styling is a big accessibility win IMO, because it disincentives developers from making a less accessible alternative for the sake of matching some design file.
The middle finger is for people like you who didnt read the first paragraph.
> A customizable version of the select element is officially in Stage 2 in the WHATWG, with strong cross-browser interest and a prototype for you to test out from Chrome Canary 130.
I worry this will lead to a bad user experience if android et al does not support it natively.
You'll have people saying "select the green option in the drop-down list to do <foo>" and people on mobile will just get the native-ui list with no styling.
I'm hoping that the documentation around this will be good, I've recently tried out CSS anchor positioning and it's riddled with examples that no longer work as the specification has been changed various times
i've re-implemented select in worse and less-accessible ways many times to satisfy some business demand. i'm very excited if this means i don't have to keep doing that.
An input + datalist still let you type whatever you want. What I want is a select with a finite list of options, but filterable so the user doesn't have to search manually. Specially necessary when you have lots of items and the sorting is not alphabetical.
The select also differentiates between the value and the presentation text. With an input you would have to use the text to find the value in your db or put the value in a hidden input in the front end.
The blog post says that "we're excited to see this feature progress through working groups and standards bodies" but doesn't link to anything that would help figure out which standard this ostensibly implements.
In the first paragraph of the article there's a link to the relevant WHATWG issue[0] (they could have used better link text though; of all people Google employees should be cognizant of link accessibility).
This is specifically not selectlist. "Previously, the Chrome team was working on the idea of a selectlist element. What's described in this post is that feature redesigned to reuse the existing select element instead."
yeah it says on that page "Due to limitations of the OpenGL Core Profile with the WebGL renderer on most platforms linewidth will always be 1 regardless of the set value." anyway yeah I was trying to be snide
I think this change seems funny to me how late it is, front-enders at this point are used to making their own customizable drop downs. But standardization is nice I suppose. And the cross browser support thing.
So after decades of developer pain, all we're getting is a better select?
Where is the native HTML datagrid (that supports sorting, filtering, paging, downloading, row/column freezing, column resizing and re-ordering)?
Where are the native HTML Tabs control? Image selector, resizer/cropper, and uploader? Toggle button? etc.
We can't even get text input to respect autocomplete directives properly. On the major browsers, giving your user id and password inputs nonsensical names seems to be required, along with numerous other hacks, to ensure that when a user is registering, the form is not auto-completed with saved passwords.
HTML is really holding us back right now.
Progress is very gradual in this space, but browser vendors are working on a lot of this stuff in the Open UI W3C community group. https://open-ui.org/
https://open-ui.org/components/combobox.explainer/ https://open-ui.org/components/switch.explainer/
> Where are the native HTML Tabs control?
You implement tabs today (aka accordions) with `<details name="tab">`. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de... "This attribute enables multiple `<details>` elements to be connected, with only one open at a time. This allows developers to easily create UI features such as accordions without scripting."
You do have to write some CSS to align tabs horizontally, but it's fine.
> Image selector?
Use `<input type="file" id="avatar" name="avatar" accept="image/png, image/jpeg" />`. Opens the OS photo picker on mobile. You can style it however you like.
> We can't even get text input to respect autocomplete directives properly.
"Properly" seems to be doing a lot of work there. "autocomplete" works fine, but it's annoying to get it right, and this kinda can't be fixed, because HTML is under a lot of backwards-compatibility constraints.
If you have autocomplete bugs to file, file them, and maybe convince the Interop group to focus on this issue. Their priorities for 2025 were just announced, but there's always next year. https://web.dev/blog/interop-2025
> it's annoying to get it right, and this kinda can't be fixed, because HTML is under a lot of backwards-compatibility constraints
Sorry, but this seems like a wild mischaracterisation, at least in regards to the problems I've had with users on Chrome. In our experience, Chrome aggressively shows an autofill prompt on almost every input it can. It also ignores the specced autocomplete=off attribute. We have observed Chrome showing a password prompt on an <input type=number> which is just bonkers. It is not hard NOT to do this.
The Chrome team thinks whatever heuristic they're using is better than allowing developers, or even end users, to control filling behaviour.
https://issues.chromium.org/issues/41163264 https://issues.chromium.org/issues/41239842
(By "autofill" I don't necessarily mean the input is automatically filled without user interaction, but sometimes a promotions shown with e.g. account login details or an address.)
The argument has been that developers are naughty and turn off autocomplete inappropriately, which worsenes accessibility. But I've never seen e.g. a tooltip option in a browser to let me, the user, fill in details when I know they're appropriate? I am merely at the whim of the Chrome algorithm.
Problem with autocomplete=off is some morons think they should use it on their login form for "security" or whatever, cause forcing users to type in passwords is "secure". So browsers wound up having to ignore it for actual security.
Browsers could have instead allowed me to right click and say "insert password because I know what I'm doing". But browsers are in the business of training users to be stupid, rather than acting as a user's loyal agent, so I guess we were mercifully spared this future.
This creates band-aid after band-aid. Like every user-agent is mozilla now.
Repeat after me: never fuck with spec implementation. If you don't like writing to a spec, write other types of software.
Let the ecosystem (website owners) face consequences of their own actions. It is better to blacklist bad actors then filling your software with bugs.
I am one of those morons who had to build a page for someone to go to the nurse's office and input all their information without it being saved for the next person who goes there to fill their information.
Problem is we (my development team) didn't own the tablets, some other team did so we couldn't force the tablets to have in private browsing.
> Problem is we (my development team) didn't own the tablets, some other team did so we couldn't force the tablets to have in private browsing.
Well, too bad, because that's exactly what the solution should be.
Yes, disabling autocomplete can be annoying, but it is possible. Usually it amounts to being more descriptive in the value of the `autocomplete` attribute, rather than simply applying `autocomplete=off`.
> We have observed Chrome showing a password prompt on an <input type=number> which is just bonkers.
"We have observed" it, but not filed a bug? Neither of the bugs you linked to exhibit that bug.
> Usually it amounts to being more descriptive in the value of the `autocomplete` attribute
No, there are many inputs where there is no sensible autocomplete value. For example, "create a new CRM customer record". This is a new customer who I have not seen before. By definition it is impossible to autocomplete.
In the past, the Chrome team advised to "make up an autocomplete value and we won't do anything with it". This advice is a) dumb and b) no longer works anyway.
> but not filed a bug?
It's clear the Chrome team has no interest in fixing this behaviour so I'm not going to waste my time. Yes, that's bad of me, but I have bills to pay.
Chrome's slogan: "L'internet, C'est moi."
[flagged]
If you're a Chromium contributor or otherwise involved, I'd be happy to chat further about this and work up a submission to demonstrate the issue with a minimal repro. But if not, I don't think they need you to stick up for them.
It's clear from the threads I did post that lots of devs are frustrated with Chrome's behaviour and the team's lack of attention to not just fixing bad behaviour, but complying with the HTML spec. Without even focusing on the type=number problem, I have spent enough time fighting other behaviour which is only an issue in Chrome.
> you only vaguely remember a bug
Thanks to that ad-hom I am now irritated, and I went back to our internal Slack to find the screenshot of the type=number bug. Sharing a screenshot here would have no real value to this discussion, but it's real.
A cursory search would show you how much frustration there is around broken autofill attributes. Such a dismissive attitude helps no one. Would you like me to paste the contents of the Jira issue I did last month working around a password input where we couldn't turn off autofill?
Believe it or not, I have observed autocomplete behavior for an input change based on its label text.
> Use `<input type="file" id="avatar" name="avatar" accept="image/png, image/jpeg" />`. Opens the OS photo picker on mobile. You can style it however you like.
This just selects the image. 99 times out 100, you want to do the same things with the image data: adjust it in some way, and save it to object storage or something. The file input is too primitive for this. And this is the theme all over, HTML control remain too primitive to do any real world rih UI with, which leads to the proliferation of JS UI libraries.
> If you have autocomplete bugs to file, file them, and maybe convince the Interop group to focus on this issue. Their priorities for 2025 were just announced, but there's always next year. https://web.dev/blog/interop-2025
Autocomplete "bugs" abound aplenty, some of which will make your jaw drop. I've been testing with Chrome and Firefox. The length to which browsers will go in a misguided attempt to be clever with auto-complete is frankly absurd. So I'm not sure they are "bugs" so much as they are a wilful refusal by browser vendors to follow the spec.
> Autocomplete "bugs" abound aplenty
No, there's just the one "bug": browsers ignore autocomplete=off.
And, as you say, the browsers regard that not to be a bug, because when they honor developers request to prevent autocomplete, users keep filing bugs on the browsers, saying "why won't you autocomplete this??"
Put something descriptive in the autocomplete, instead of "off", and you're usually fine.
Consider the "State of HTML" survey of form pain points. https://2024.stateofhtml.com/en-US/features/forms/#forms_pai...
See also the "missing elements" section. https://2024.stateofhtml.com/en-US/usage/#html_missing_eleme...
An image cropper didn't make the list. Data table did! But it's pretty complicated, and, as I said, progress is slow. Partly that's for backwards compatibility reasons, and partly it's because you have to get Apple, Google, Microsoft, and Mozilla to all agree on anything, and that's really hard.
Autocomplete is on the list of pain points. But it's wayyy further down the list than having a customizable `<select>`. Styling & customization, validation, and `<input type=date>` are all bigger pain points than autocomplete.
You sound like you are not ready to face reality. I put it to you that I have observed _numerous_ deviations from the autocomplete spec that defy all logic.
If you want a laundry list of them, I'm ready to list them all in their gory details here, but I suspect you have made up your mind irrespective of the facts.
> 99 times out 100, you want to do the same things with the image data: adjust it in some way, and save it to object storage or something.
That's kind of a bonkers expectation for the browser to fill. It's like expecting that <input type="audio" /> should let me crop the audio and add reverb to it. That's two specific manipulations out of untold thousands, and squarely within the purview of a different app. https://editor.audio/ (never used this, just an example)
> This just selects the image. 99 times out 100, you want to do the same things with the image data: adjust it in some way, and save it to object storage or something. The file input is too primitive for this.
That's not true at all. Obviously there's no `adjustinsomeway` or `savetoobjectstorage` attribute on the <input> element, but you can trivially grab the selected files, read them, and act on them with JavaScript: https://developer.mozilla.org/en-US/docs/Web/API/File_API/Us...
> and act on them with JavaScript
I thought the whole point was to avoid JavaScript, by having rich UI components built right into the browser
Sure, but what kind of image manipulation do you think would actually belong in the HTML spec? That just seems way out of scope to me.
Why not something similar to what iOS has? Or Windows?
They all have functional built in image editors. They're very light weight, and are not meant to replace a dedicated tool, but if all you want to do is crop an image or other relatively simple tasks, there's ample evidence on other platforms that providing these minimal tools is big value to users.
> This just selects the image. 99 times out 100, you want to do the same things with the image data: adjust it in some way, and save it to object storage or something.
This is probably the reason why someone invented the <canvas> element?
Datagrid is mysteriously missing on several newer desktop UI frameworks too, which effectively makes those frameworks ill-suited for a whole range of desktop applications. The only place reasonably batteries-included versions of those widgets can be found are in the old guard toolkits like AppKit, win32, MFC, Qt, GTK, etc.
> Where is the native HTML datagrid
Which parts of a datagrid should a browser provide? I'm familiar with AG Grid [1] and the API surface is enormous. Aligning browsers on a feature set would be challenging.
Maybe there's a core set of functionality, like Flutter's GridView or QML https://doc.qt.io/qt-6/qml-qtquick-gridview.html.
[1]: https://www.ag-grid.com/
The simplest would be to follow the aria role=“grid” spec, ideally with sortable columns. IMO it doesn’t need the kitchen sink AG Grid approach just a sane way to semantically build a data grid with proper accessibility.
https://www.w3.org/WAI/ARIA/apg/patterns/grid/examples/data-...
It has to handle every possible use case for a grid. You’re thinking of your use case. The spec needs to handle everything else. I don’t see how that’s manageable.
Does it though?
A good spec really only needs clear principles. At a minimum, it should clearly explain what it does do, and also clearly explain what it does not do.
You don't need to have every edge case covered to build an API for datagrids. iOS has had native DataGrids for ages, Windows, macOS, Android. They all have this stuff built in. Other platforms have figured out how to provide these API surfaces.
Why does the web have to be seen as a special unicorn that can't have good baseline components like these platforms?
Are any of the examples you gave an open standard with multiple implementations from different companies? If Apple gets their implementation wrong, they can always deprecate an API and move forward. If they want to throw out an old implementation and deprecate that completely and start over, they can do that. The Web standard depends on agreement by multiple large organizations. That level of communication slows everything down. If they get an API wrong, we’re stuck with it forever.
That’s why the web is a special unicorn. It’s very different than those platforms. Web standards should be small and composable. They shouldn’t try to solve every problem. I get why you would want a data grid. Maybe in your work it’s a common pattern. But on the broader web and in all of the documents that are out there, it’s on a minute fraction of them. It’s simply not worth the effort. Too much effort, too little gain.
>Are any of the examples you gave an open standard with multiple implementations from different companies?
ECMAScript / JavaScript. It has evolved at a faster pace since the introduction of ES6, and we been getting new features every year for awhile now. Given the types of features they're willing to ship with the languag and that many of the same people working on the HTML spec work on ECMAScript, it seems 'niche' isn't an issue (simply look at how many features have been added specifically only for classes vs the amount that the language construct of class is actually used. Its tiny in usage, but they've added alot of class specific features)
Other notable examples include the C and C++ standards (there are differing vendor implementations depending on platform which while annoying are largely well known how to navigate). Linux operating systems - the amount of incompatibility between linux distros is shockingly small all things considered.
I'm sure there are others I'm not able to think of as well, but this isn't special to the web by any means.
At minimum filtering and sorting should be handled by the browser, including async for both of those.
Pagination could be argued as well, but at least that's simple-ish to implement (but still, it's such a common UI pattern that it ought to be handled in a unified way by browsers IMO)
Look at how much effort has gone into just getting a stylable select box. Look at tooltips. A data grid is several orders of magnitude higher in complexity than both of these. You are severely underestimating the complexity of your ask. HTML/JS/CSS is not supposed to solve all your UX problems. It’s a toolkit for building UIs, not a framework.
Is it not the design by committee approach that slows down the design consensus on things like these? Just complex is it to design a spec for a stylable select box that is reasonable for most use cases?
If it has to take decades to agree on a design for a stylable select box, then there is something fundamentally broken with the approach.
For an open standard, how do you design it without agreement among a committee? Just let Google go rogue and define it? And have you ever worked in a large company? Have you seen how difficult it is to get any large group of people to agree on ANYTHING? These specs depend on the agreement of multiple large companies coming together. Each one of those companies is made up of many subcommittees who have to come into agreement with each other.
While maybe you could imagine a straightforward technical implementation (and I think you’re overlooking the complexity of getting the API right while making it extensible), the social engineering involved to make this happen would be Herculean. And it would be for an element that’s on less than 1% of web pages. If you really want a data grid, I’d suggest learning how to code one. It’s a fun challenge, and implementing basic features like sorting and filtering isn’t difficult using a modern framework. If it is difficult for you, then I’d suggest that it would be a GREAT experience to try. Then imagine how you’d make it extensible for unknown use cases.
The main reason it took decades for a stylable select box is because for two decades, we were just told “Don’t style select boxes. It’s bad for usability,” which was a mistake. We’ve only started to overcome that mindset in the past few years. The work on stylable select boxes only started in the past few years.
> For an open standard, how do you design it without agreement among a committee?
There's a difference between design-by-committee, and approval by committee. I'm arguing against the former. This is not to say that I have much hope that my approach will prevail, but it is an indictment of the W3C/WHATWG that they have not figured out a better process for producing technically excellent and coherent designs/specs in reasonable time.
Just invite submissions from small teams that each have produced a coherent design, and then the hard process of agreeing/voting on them will be a bit easier.
> If you really want a data grid, I’d suggest learning how to code one.
I have designed and implemented highly sophisticated data grids, and I have published related libraries on NPM. I wonder what in my comments makes you think I lack the competence or experience to implement one.
The problem is the JS bloat that we have to deal with. It is ugly that we have to load megabytes of JS to render any reasonably sophisticated web UI. Multiply that by the millions of sites that have to do that, plus all the upstream dependencies that are loaded with that, and also consider all the security/privacy issues with so much JS, and hopefully you'll begin to understand the critical need for a revamp of the HTML space.
Imo it’s not html, it’s browser vendors. There’s a decent specification for the `autocomplete` attribute: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...
It is actually a reaction to websites doing stupid things to try and prevent password auto-fill. The sites are fighting against security in a misguided attempt to improve security, so the browser vendors added a bunch of heuristics to try and correct these situations and you end up with the mess we have.
Equally having to jump through extra hoops to prevent autocomplete where you don't want it is frustrating, like in admin interfaces where you might be updating someone else's name.
It's an arms race of stupidity.
RE autocomplete in Chrome. The only thing we've found to work reliably is ensuring that all inputs are in form elements. Any inputs outside forms are going to have inappropriate autocomplete prompts. It's extremely annoying but at least this works for now.
(I say "for now" because who knows when the Chrome team will change their heuristic?)
Nah, this does not work reliably. The weirdness I've found regarding autocomplete will fill a book.
I'd love to read a "Falsehoods programmers believe about..." post about this!
Why wouldn’t you put your inputs in a form element?
> Why wouldn’t you put your inputs in a form element?
Not all inputs are form-submission data.
For example a datalist-backed input to scroll to a specific page/chapter/section/subsection in a long document. You might populate the datalist with hundreds of entries so you don't have a long list of links that the user will have to scroll through in the sidebar. You can perform the scroll on the change event of the input.
That's a good UI for the user, instead of presenting a long list of links for the user to browse/search through, they simply have the input auto-suggest based on the populated datalist.
I mainly work on a large complex SPA with UX that does not often look like a form, but does have lots of inputs. These days I'm much bigger on semantic HTML, to the small extent it matters in our case, but there is a large burden of pages which were just div soup and loose inputs.
HTML can never be meaningfully improved, that fact is at the heart of the current attitudes by the browsers. We are 20 years into the takeover from the W3C and still can't even do a PUT request without JS, nevermind anything approaching even one tenth of the capability of XForms.
The best we'll get is little improvements like this which everyone will ignore because ChatGPT will recommend some react component instead.
Right? There are already dozens of deprecated elements, just deprecate these too and give us new ones that actually do what they're supposed to do and don't require us to know the entire history of HTML just to do a dang <select> that isn't ugly.
I'm just glad I don't have to support IE6 anymore.
Internet Explorer had a native Data Grid with two-way data binding and much more.
https://schepp.dev/posts/today-the-trident-era-ends/#data-gr...
That's a great article about advancements in IE that still haven't all been matched.
> Where is the native HTML datagrid
Imagine a world where instead of letting IE die, microsoft decided to add a <XLS> tag in the early 2000. The most used nocode database in the world directly in the browser. In 2000.
You do realize that that was the big problem with IE security in those days: ActiveX. You literally could embed an Excel file in your HTML page.
You could embed any native code and it would just be a small yes/no dialog to download and run it.
I'm not finding any of those proposals on the whatwg html repo, mind linking them?
That's my point, they are not on the roadmap, although they absolutely should be, IMO.
The W3C and WHATWG have their priorities mixed up.
I think some of this stuff isn't the responsibility of HTML. If HTML already has a full autocomplete spec, isn't it the fault of browsers/extensions/OS if the implementation is broken? Or are you saying the spec is too ambiguous?
A lot of stuff becomes redundant under the framing that HTML is designed to provide semantics, not a user interface. How is a toggle button different from a checkbox? How are tabs different from <details>, where you can give multiple <details> tags the same name to ensure only one can be expanded at a time?
Image manipulation is totally out of scope for HTML. <input type="file"> has an attribute to limit the available choices by MIME type. Should there be special attributes for the "image" MIME type to enforce a specific resolution/aspect ratio? Can we expect every user agent to help you resize/crop to the restrictions? Surely, some of them will simply forbid the user from selecting the file. So of course, devs would favor the better user experience of accepting any image, and then providing a crop tool after the fact.
Data grid does seem like a weak spot for HTML, because there are no attributes to tell the user agent if a <table> should be possible to sort, filter, paginate, etc. It's definitely feasible for a user agent to support those operations without having to modify the DOM. (And yes, I think those attributes are the job of HTML, because not every table makes sense to sort/filter, such as tables where the context of the data is dependent on it being displayed in order.)
Generalized rant below:
Yes, there are pain points based on the user interfaces people want to build. But if we remember that a) HTML is a semantic language, not a UI language; and b) not every user agent is a visual Web browser with point-and-click controls, then the solution to some of these headaches becomes a lot less obvious. HTML is not built for the common denominator of UI; it's built to make the Web possible to navigate with nothing but a screen reader, a next/previous button, and a select/confirm button. If the baseline spec for the Web deviates from that goal, then we no longer have a Web that's as free and open as we like to think it is.
That may be incredibly obvious to the many Web devs (who are much more qualified than me) reading this, but it's not something any end user understands, unless they're forced to understand it through their use of assistive technology. But how about aspiring Web devs? Do they learn these important principles when looking up React tutorials to build some application? Probably not—they're going to hate "dealing with" HTML because it's not streamlined for their specific purpose. I'm not saying the commenter I'm replying to is part of that group (again, they're probably way more experienced than me), but it reminded me that I want to make these points to those who aren't educated on the subject matter.
Safari already has toggle buttons and autocomplete directives.
Apple’s webkit team killed customised built-in elements by refusing to implement them on ideological grounds, so you get a dripfeed of piecemeal solutions instead.
Apple is actively sabotaging the web for a number of years now. They don't want web apps to be able to compete with native iOS apps.
And they prohibit different browsers from the app store, so users don't even have a choice.
Those reasons are not ideological and there's a new proposal that doesn't have the downsides of the original spec and enables new use cases discovered since: https://github.com/WICG/webcomponents/issues/1029
Nothing with customizable built-ins would give you what the original commenter asked for
you forgot the most important one, where s the browser native virtual list, grid and table?
> Where is the native HTML
14 years have been wasted on making web components happen, and they still offer... nothing really, and people already advise to skip large portions of their specs (Shadow DOM) even if you adopt them.
Imagine if the literally millions of dollars spent of them were spent on something like https://open-ui.org/ (started by Microsoft of all companies and now also completely overrun by Googlers)
I find web components very useful. Yes, I avoid shadow DOM as it only makes things more complicated for me, but having bits of functionality grouped in a new tag is great.
Yeah, the "HTML Web Components" can be useful: https://adactio.com/journal/20618 and https://blog.jim-nielsen.com/2023/html-web-components/
> You just take some normal HTML markup, wrap it with a custom element, and then write some JS to add capabilities which you can then style with regular CSS! Everything’s of the Light Side of the Web. No need to pierce the Vale of Shadows or whatever.
Ah ! Yes, that's basically me.
Please forgive my tangential rant on the DOM. You have an input field where type=number and when you read it with .value() you get a string. Cmon man.
There is .valueAsNumber. input.value returns a string, regardless of the input type. Making the return type dynamic would be worse, imo.
> Where is the native HTML datagrid (that supports sorting, filtering, paging, downloading, row/column freezing, column resizing and re-ordering)?
That's called <table>.
https://news.ycombinator.com/item?id=42163128
https://news.ycombinator.com/item?id=39489285
I'm not sure how those comments address the need for a built-in table element with the said features. Can you explain, or link to demo that shows what you are trying to say?
https://www.mozilla.org/en-US/firefox/features/picture-in-pi...
https://old.reddit.com/r/PleX/comments/mr1k8m/just_discovere...
https://news.ycombinator.com/item?id=43121881
If this will stop the proliferation of terrible JavaScript implementations of <select>, I'm here for it.
I know LoC is a terrible metric, but it always shocks me that things like react-select require 30k LoC.
21% the size of the code of the Apollo Lander to configure/style a select dropdown.
react-select does a lot more than style the select though, so even after this new standard for customizable selects is supported everywhere, react-select will still have about the same level of complexity as it does now.
But does it get even 21% of the way to landing on the moon?
Maybe 21% of astronauts have used select components made with react-select. That’s approaching moon territory!
I salute your optimism. Really, this just gives developers more options to make designers lives more miserable, and vice-versa.
My thought was it is giving designers more options to make users’ lives more miserable.
I am honestly just blown away Google invested effort into a web standard that actually improves the web versus the dozens of web platform projects designed to let websites slurp more data.
This is something I actually look forward to being able to use when Firefox gets it.
There’s got to be a happy medium between using canvas to make the controls you actually want and browser-provided one-size-fits-nobody controls. I really thought MS was onto something with Silverlight’s with XAML but that died.
Ah, customizable for web developers, not end users.
(And yes, I'm still bitter about you all wrecking my scroll bars.)
You can override styling with user stylesheets. On desktop. Need the same for i{,Pad}OS.
There are some iOS apps that work as Safari extensions and enable Greasemonkey scripts. I use one called Userscripts.
I think that CSS is excessive, that I often disable it and that the excessive design means that sometimes the way to fix it is to add more stuff, which just makes it more messy. (In many cases, it would be helpful to put things that only the end user controls and that document author does not control. Yet, they don't really design them for that very well.)
I've been doing front-end since the days of IE5 and I'd be rich if I had a penny for every time I've had to do a custom "select". It's a pain to use third-party libraries for this, but it _is_ a solved problem and doesn't require that much extra code.
I think we should welcome all efforts to have a standardized, modern select component in the HTML spec. Would save a lot of trouble.
Which libraries have solved this problem? I recently tried several of the most recommended standalone JS libraries for implementing a <select> with icons and a custom layout, but each single one of them was seriously lacking in some way.
Even with an average software engineer compensation, you probably got paid a lot more than a penny for every custom "select" you implemented :)
It's not a solved problem. There are maybe two libraries out there that are customizable, performant, and don't break things like keyboard navigation and accessibility
This is the correct answer, if perhaps too optimistic on there being two of them.
Yeah the problem is when you need to create a custom select without using a 3rd party library, and you want to make sure the interactions are accessible and up to parity with native selects. Then you have to add tons of event handlers, aria attributes, refs for handling outside clicks, etc etc.
I spent days building this little perfect dropdown select thing, that is a hundreds lines of code and even more docs explaining what the hell is going on. Someone wasted the same amount of time before me. Someone else spent a lot of time before them. And so on.
I wish we have had more browser native implementations including some notion of virtual lists so the browser would not choke when rendering a lot of content.
---
Eventually, this would be same as border-radius. It will get implemented and we'll forget about that forever.
I thought the promise of Web Components was also about this: make a control once, make it styleable, let everyone reuse it.
I wonder why is this not happening widely.
It's not surprising, really: web components suck for having highly-customizable inputs.
1. You get HTML attributes to pass data in, or JavaScript properties. If you're in React, you'd just use a React component and skip web components. If you're in vanilla HTML, you can't just write HTML, you have to build the component with the DOM.
2. There's no real standard to making web components look the way you want them to. You can't just use CSS (you have to have the shadow root "adopt" the styles). Your point of "make it styleable" is actually one of web components' biggest weaknesses (IMO).
3. Web components are globally registered. React/Vue/Svelte/etc. components are objects that you use. You end up with a mess of making sure you registered all of the components you want before you use them (and not registering the ones you don't use) and hope no two packages you like use the same name.
> There's no real standard to making web components look the way you want them to. You can't just use CSS (you have to have the shadow root "adopt" the styles).
Not exactly. There’s the ::part() pseudo-element selector, which allows you to target an element in the shadow tree that has a matching part attribute.
https://developer.mozilla.org/en-US/docs/Web/CSS/::part
Which is honestly kind of wild. You can't, as far as I know, customize pseudoelements of the part. You can't customize them in context (no striped table rows). You kind of have to just pray that custom properties work like you hope.
Because web components themselves break even in the expected situations? And need 20+ new spec to make them work? And because they are neither low level enough nor high level enough to be useful for the use case you described?
Web components are pretty terrible, and do not work as you would expect them to. Take this, for example
So <some-element> is a web component that adds extra features to the input. So it constructs a shadow DOM, puts the <input> into it, styles the input appropriately, etc. And before the web component finishes loading, or if it fails, or if web components aren’t supported in some way, it still works like a normal <input>.Now take this:
Same thing. You’ve got a normal <textarea>, and the web component adds its extra stuff.Now take this:
Same thing, right? Nope! This doesn’t work! Web components can only style their immediate children. So the first web component can style the <input> element, the second web component can style the <textarea> element, and the third web component can style the <select> element… but it can’t style the <option> element.Web components are full of all of these random footguns.
> Web components can only style their immediate children.
This isn’t true at all. You’re doing something incorrect when creating your shadow root or adding your styles. (“Web components” aren’t really a thing - it’s a marketing term for a set of technologies - so I assume that you’re talking about custom elements with shadow roots here.)
Refer to example 4 in the CSS Scoping specification:
> It will not select #three (no slot attribute) nor #four (only direct children of a shadow host can be assigned to a slot).
— https://drafts.csswg.org/css-scoping/#example-7cc70c2d
I’m talking about the #four case.
Alternatively, refer to the issue that was opened in the web components issue tracker here:
> > you can only select a direct item within the slot
> That is by design. See #331 for details.
> We don't have a plan to support an arbitrary selector for ::slotted.
— https://github.com/WICG/webcomponents/issues/594#issuecommen...
> “Web components” aren’t really a thing
This is an empty nitpick. The people writing the specs call them web components, the people implementing them call them web components, the people writing them call them web components. There is nothing wrong with calling them web components.
> I assume that you’re talking about custom elements with shadow roots here.
You don’t have to assume anything. I explicitly said that it constructed a shadow DOM.
Yeah, slotted elements have to be direct children, but you can select any descendant in CSS. That text is only referring to the ::slotted() pseudo-element.
- Why is picker a function like `::picker(select)`, and not a CSS pseudo class like `::before` to select the `select`'s `picker` component? I.e., `select::picker` makes a lot more sense to me.
- What about multi-choice (`multiple` attribute) `select`s?
Because it's been trendy to introduce a new unintuitive syntax with every new CSS feature.
I am genuinely afraid for the future of CSS as it is becoming increasingly more complex, meanwhile most people haven't been able to properly utilize or understand it for the last decade even without all of that additional complexity.
[dead]
I don’t really see if there’s now an option to further improve the select with JavaScript to add, for example, a search textbox for filtering.
And what about the nearly unusable (on desktop) <select multiple>?
I don’t understand the hatred for select multiple on desktop. It’s a list box that uses standard UI conventions that have been present for three or four decades now.
They're probably referring to it not being usable without keyboard, unlike regular select, or checkboxes, or anything else sans a text field. Specifically, to select elements one by one, you need to hold down Ctrl (on Windows; modifiers for other OSes are different).
For better or worse, this element is not obvious for those who didn't grow up using desktop computers 10+ years ago.
I use it in one place in my app, and even with me putting text right above it saying something like "ctrl+click to select multiple entries", I still periodically get emails from confused users. No idea what the actual % is, but it's gotta be some non-trivial fraction of people who just have no idea how to use that thing.
The thing is, this is a catch-22 problem: if everyone used the default multiple select, people would know how to operate it (and they’d be able to transfer their knowledge from how the control works elsewhere in their os to the web: for example, if you know how to select multiple files in Finder, Windows Explorer or in a open file dialog, it works exactly the same way in the multiple select control). But, because web developers have decided to invent a 1,001 different multiple selects, the default control is inaccessible.
The real issue I have with the web is everyone has broken user interface consistency across the platform with custom web controls where the default controls would be fine.
The trouble with the multiple select is that you have to use it usually when that's what the control is. Users who don't know to control-click can do things like moving files one at a time in the OS, but rarely (never?) is an OS showing you a control like that that makes you use ctrl-click to use it at all, vs. a list of checkboxes or whatever, or contexts like selecting files where you usually can accomplish your goal piecemeal.
I agree that the feature/appearance/accessibility inconsistency you get from reimplementing the controls is a problem, but I think the right way to fix it is to raise that common floor of what the web platform provides. People want, e.g., comboboxes, they've been around forever in UI toolkits, but the web's standard answer for them is still pretty terrible, so it's no surprise that people reach for the libraries that replace the whole thing.
search textbox: would be supported under the even 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/
How about the literally unusable <select multiple> on mobile? You can't select more than one option on a touch screen...
Seems to work fine on iOS Safari and Chrome
They been talking about this for a long time.
In fact, I remember at some point, they were trying to sell the idea of exposing all the form inputs to use the `::part` API, since under the hood form inputs share the same general logic of custom elements, If I recall correctly.
From the looks of it, didn't work out that way though.
And I think its for the best. I like this proposal more, even though delivering the `::part` API to everyone (not just web component users) would have likely been faster
Using ::part() was a bad idea. Part is for user-defined pseudo elements. The platform can just define real pseudo elements. I argued against using `::part()` in spec threads, and I haven't looked back recently, but I think that argument won over.
Yes please, like everybody else I had to make a custom one https://radogado.github.io/n-select/ and will be happy to move to a rich standard
I love the way the menus reveal themselves in-place, very nice touch.
This is a very good start, I don't think it'll replace a lot of the custom code/comboboxes that are seen in react-land without search (unless I missed it).
Maybe, but adding search to this element is still a lot easier than a fully custom one.
I've been griping about html's select for some tome - https://paulhammant.com/2013/01/31/appdev-glass-ceiling-revi... - great news
What's the point of Chrome-only css.
The point of Chrome-only CSS (vendor-prefixed features) would be to allow Chrome or any other vendor to expose styling functionality to CSS authors in valid CSS syntax in ways that won't impede future standardization efforts (like writing non-standard CSS would do) or interfere with that same CSS being processed by other vendors.
But this article isn't an example of Chrome-only CSS, this is about a change to the standard select element to make it customizeable in a standard way. It's not fully frozen yet, so they're seeking feedback and still working on it, so if you have input to give about this feature I think they'd welcome it. This blog post was about Chrome introducing experimental support for it, likely so developers can experiment with it and provide more valuable feedback towards its standardization!
So websites "look better in Chrome", that's what Google wants.. but it's ultimately not good for us, so I hope developers don't fall for this..
Why dont you read the article and see for yourself.
> A customizable version of the select element is officially in Stage 2 in the WHATWG, with strong cross-browser interest and a prototype for you to test out from Chrome Canary 130.
This doesn't change the fact that it will only work in Chrome for a long time before it ships to firefox.
So? Damned if you do, damned if you don't?
Don't do something - OMG, Chrome is dragging their feet. Why can't they do it? It is standards track after all
Do something - umm, it'll be only on Chrome for a really long time.
At least be a bit consistent with your qualms.
[dead]
Reminds me of when we had to use browser hacks for IE.
[flagged]
https://news.ycombinator.com/newsguidelines.html
> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that".
It's a middle finger to people who try to set some standards and maintain them for a while. Also, a middle finger to accessibility people.
It's absolutely not that- it's an early implementation of a drafted WHATWG standard in the "iteration" phase, put behind a development build and a development flag so people know that it isn't stable and might change and nobody who doesn't explicitly opt in will be affected. This is literally made to allow "people who try to set some standards" to test their proposed standards and iterate on them before finalizing the proposal.
As far as accessibility, the native browser select is almost always going to be more accessible than someone making a custom input using JavaScript so they can add some styling control. Having the native version support basic styling is a big accessibility win IMO, because it disincentives developers from making a less accessible alternative for the sake of matching some design file.
The middle finger is for people like you who didnt read the first paragraph.
> A customizable version of the select element is officially in Stage 2 in the WHATWG, with strong cross-browser interest and a prototype for you to test out from Chrome Canary 130.
I worry this will lead to a bad user experience if android et al does not support it natively.
You'll have people saying "select the green option in the drop-down list to do <foo>" and people on mobile will just get the native-ui list with no styling.
I'm hoping that the documentation around this will be good, I've recently tried out CSS anchor positioning and it's riddled with examples that no longer work as the specification has been changed various times
this is a huge win for accessability.
i've re-implemented select in worse and less-accessible ways many times to satisfy some business demand. i'm very excited if this means i don't have to keep doing that.
Neat. Can I put an input inside the select so I can filter options?
> Neat. Can I put an input inside the select so I can filter options?
How will input-inside-select be better than a datalist?
(Genuinely curious, not being facetious)
An input + datalist still let you type whatever you want. What I want is a select with a finite list of options, but filterable so the user doesn't have to search manually. Specially necessary when you have lots of items and the sorting is not alphabetical.
The select also differentiates between the value and the presentation text. With an input you would have to use the text to find the value in your db or put the value in a hidden input in the front end.
I would like to know this as well.
Wonder what is the point of this, all these functionalities are available in any third party libraries since ages.
Now, what’s the <https://caniuse.com/> link to this feature?
It's a bit early for browser support given that it's not usable in Chrome. A better place to look for information about the status is probably here:
https://chromestatus.com/feature/5737365999976448
I think it might be this one?
https://caniuse.com/selectlist
The blog post says that "we're excited to see this feature progress through working groups and standards bodies" but doesn't link to anything that would help figure out which standard this ostensibly implements.
In the first paragraph of the article there's a link to the relevant WHATWG issue[0] (they could have used better link text though; of all people Google employees should be cognizant of link accessibility).
[0]: https://github.com/whatwg/html/issues/9799
This is specifically not selectlist. "Previously, the Chrome team was working on the idea of a selectlist element. What's described in this post is that feature redesigned to reuse the existing select element instead."
Yeah now if they can go ahead and make ThreeJS line thickness be more than 1 that'd be greeattttt....
edit: this is a joke about "OpenGL Core Profile with the WebGL renderer" which I'm not sure if Chrome (browser) would be responsible for
https://threejs.org/docs/index.html#api/en/materials/LineBas...
const material = new THREE.LineBasicMaterial( { color: 0xffffff, linewidth: 1, linecap: 'round', //ignored by WebGLRenderer linejoin: 'round' //ignored by WebGLRenderer } );
yeah it says on that page "Due to limitations of the OpenGL Core Profile with the WebGL renderer on most platforms linewidth will always be 1 regardless of the set value." anyway yeah I was trying to be snide
Ah, I see. Seems like there's a bunch of 2D cruft in the graphics hardware that hasn't been touched since 3D became possible.
I think you need to expand on the edit even more for this to make sense.
I think this change seems funny to me how late it is, front-enders at this point are used to making their own customizable drop downs. But standardization is nice I suppose. And the cross browser support thing.
HTML is getting complex every day