[HN Gopher] Customizable HTML Select
___________________________________________________________________
Customizable HTML Select
Author : dsego
Score : 128 points
Date : 2025-02-20 12:13 UTC (10 hours ago)
(HTM) web link (developer.chrome.com)
(TXT) w3m dump (developer.chrome.com)
| ge96 wrote:
| 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
| kreetx wrote:
| I think you need to expand on the edit even more for this to
| make sense.
| ge96 wrote:
| 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.
| hnuser123456 wrote:
| 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 } );
| ge96 wrote:
| 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
| hnuser123456 wrote:
| 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.
| no_wizard wrote:
| 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
| spankalee wrote:
| 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.
| teddyh wrote:
| Now, what's the <https://caniuse.com/> link to this feature?
| InsideOutSanta wrote:
| 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.
| matt_kantor wrote:
| 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
| rjmorris wrote:
| 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."
| jchw wrote:
| 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
| Sateeshm wrote:
| What's the point of Chrome-only css.
| err4nt wrote:
| 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!
| zb3 wrote:
| 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..
| bitpush wrote:
| 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.
| chente wrote:
| Reminds me of when we had to use browser hacks for IE.
| drivingmenuts wrote:
| 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.
| bitpush wrote:
| 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.
| naet wrote:
| 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.
| bitpush wrote:
| Did you even read the fucking article?
|
| > 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.
| LordDragonfang wrote:
| 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".
| endemic wrote:
| If this will stop the proliferation of terrible JavaScript
| implementations of <select>, I'm here for it.
| drivingmenuts wrote:
| I salute your optimism. Really, this just gives developers more
| options to make designers lives more miserable, and vice-versa.
| layer8 wrote:
| My thought was it is giving designers more options to make
| users' lives more miserable.
| jimbob45 wrote:
| 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.
| jjcm wrote:
| 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.
| deanc wrote:
| 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.
| crab_galaxy wrote:
| 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.
| hassleblad23 wrote:
| I think we should welcome all efforts to have a standardized,
| modern select component in the HTML spec. Would save a lot of
| trouble.
| bmk44 wrote:
| Even with an average software engineer compensation, you
| probably got paid a lot more than a penny for every custom
| "select" you implemented :)
| mopsi wrote:
| 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.
| rado wrote:
| 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
| threatofrain wrote:
| I love the way the menus reveal themselves in-place, very nice
| touch.
| Pesthuf wrote:
| 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>?
| LordShredda wrote:
| How about the literally unusable <select multiple> on mobile?
| You can't select more than one option on a touch screen...
| jacobsimon wrote:
| Seems to work fine on iOS Safari and Chrome
| fiddlerwoaroof wrote:
| 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.
| TeMPOraL wrote:
| 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.
| bityard wrote:
| Ah, customizable for web developers, not end users.
|
| (And yes, I'm still bitter about you all wrecking my scroll
| bars.)
| jagged-chisel wrote:
| You can override styling with user stylesheets. On desktop.
| Need the same for i{,Pad}OS.
| macNchz wrote:
| There are some iOS apps that work as Safari extensions and
| enable Greasemonkey scripts. I use one called Userscripts.
| zzo38computer wrote:
| 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.)
| bushido wrote:
| 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).
| prmph wrote:
| 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.
| sa46 wrote:
| > 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/
| crab_galaxy wrote:
| 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-.
| ..
| dimal wrote:
| 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.
| tisc wrote:
| 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...
| nonchalantsui wrote:
| I'm not finding any of those proposals on the whatwg html repo,
| mind linking them?
| prmph wrote:
| 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.
| robertoandred wrote:
| Safari already has toggle buttons and autocomplete directives.
| dfabulich wrote:
| 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
| crabmusket wrote:
| > 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.
| prmph wrote:
| > 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.
| rafram wrote:
| > 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...
| prmph wrote:
| > 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
| rafram wrote:
| 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.
| crabmusket wrote:
| 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?)
| inopinatus wrote:
| 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.
| greiskul wrote:
| 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.
| cosmic_cheese wrote:
| 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.
| thrance wrote:
| 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.
| user3939382 wrote:
| 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.
| paul_h wrote:
| I've been griping about html's select for some tome -
| https://paulhammant.com/2013/01/31/appdev-glass-ceiling-revi... -
| great news
| akersten wrote:
| - 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?
| mary-ext wrote:
| 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
| mattlondon wrote:
| 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.
| CafeRacer wrote:
| 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.
___________________________________________________________________
(page generated 2025-02-20 23:00 UTC)