[HN Gopher] The <select> element can now be customized with CSS
___________________________________________________________________
The <select> element can now be customized with CSS
Author : tosh
Score : 320 points
Date : 2025-03-31 09:11 UTC (13 hours ago)
(HTM) web link (developer.chrome.com)
(TXT) w3m dump (developer.chrome.com)
| ljoshua wrote:
| The challenge till this is widely supported (caniuse.com
| currently pegs it at 46% globally [1]) will be using this as a
| progressive enhancement that does not provide a worse or unusable
| experience for users with browsers not supporting it yet.
|
| In other words, don't include critical information or
| functionality in the new styling that isn't available in the
| underlying plain select element! But such is always a good
| practice anyway.
|
| Very nice to see this taking shape though! Should be a _huge_
| improvement over the div monster that custom select box
| replacements often are. :)
|
| [1] https://caniuse.com/mdn-css_properties_appearance_base-
| selec...
| no_wizard wrote:
| The perpetual 5 year problem of web development. I wish there
| was a way to do forward standards
| paddy_m wrote:
| This is true, and I try not to get eager about new browser
| improvements for this reason. But look at the porgress over
| time in browser abilities, it's astounding.
|
| The days are long but the years are short.
| simiones wrote:
| You'll probably still keep a <div>-based control in your page,
| and selectively hide the <select> based one or this one, or
| generate different HTML for different browsers if you can do
| that.
| ddoolin wrote:
| I agree that this is a huge improvement, but it's also over a
| decade late IMO. This should've been accomplished well before
| now, especially given that the issue has been there since the
| beginning.
| pclmulqdq wrote:
| Because frontend is frontend, Javascript frameworks dominated
| the conversation even for silly things like basic web forms
| for the past 15 years. Basic HTML/CSS is now catching up to
| the fact that not everyone wants to run a Javascript
| monstrosity for custom styling on very basic tasks.
| no_wizard wrote:
| The prevalence of JS and JS backed components is due to the
| reluctance of browser vendors to introduce new HTML
| elements that everyone has been lobbying for in the same
| time period.
|
| By and large browser vendors for the longest time, even
| today still in many respects, repeatedly ignore pleas for
| more elements that cover common use cases.
|
| Even when they do arrive, they can be half baked - like
| dialog or details / summary - and that doesn't help matters
| lelanthran wrote:
| > Even when they do arrive, they can be half baked - like
| dialog or details / summary - and that doesn't help
| matters
|
| How are those half-baked? No smooth transition for
| details/summary, maybe?
|
| Dialog seems to work well enough with little to no
| javascript required: <dialog>
| <h3>Warning:</h3> ... <button
| onclick='this.closest("dialog").close()'>Dismiss</button>
| </dialog>
|
| My personal bugbear is the date/time input - FF doesn't
| even show a click element for time, you have to type in
| the time.
| no_wizard wrote:
| There's some quirks with the API around open vs openModal
| if you aren't aware of the accessibility implications you
| may not even realize this is the case.
|
| Forms have some special quirks inside of a dialog.
|
| The biggest thing though, is for the life of me I don't
| understand why you can't open and close a dialog without
| JavaScript. There's no way to do it.
| tracker1 wrote:
| I'm with you... would be nice to have:
| <button type="open-dialog" target="dialogId">Open
| Dialog</button> ... <dialog id="dialogId">
| <button type="close-dialog">Close Dialog</button>
| </dialog>
|
| It would just make so much sense.
| codedokode wrote:
| You can't make enough HTML elements to make everyone
| happy. This was the wrong idea from the start.
| hombre_fatal wrote:
| Forms are hard because they are the most stateful and most
| ubiquitous UI component that everyone comes in contact
| with. HTML has a few barebones tools to help you out, but
| they aren't good enough for the best user experience if you
| really wanted to polish a form like show errors exactly
| when you want to show them and only allow submission
| exactly when you want to allow it and represent error
| states in much better ways.
|
| It's especially obvious once you're making forms outside of
| HTML and you realize that it's not any simpler with any
| less UX consideration. The only thing that changed was the
| language you're writing that polish in.
| true_religion wrote:
| I somehow feel Safari drags its feet on basic things platform
| improvements because they want to focus on iOS apps instead.
| arp242 wrote:
| Eh; the standard is two weeks old. Written by someone
| working for Apple by the way.
| bsimpson wrote:
| > But such is always a good practice anyway.
|
| One more reminder to develop for people who may not perceive
| color and shape as you do. If you're hiding critical
| information in your menu styles, that information is presumably
| inaccessible to people who are using a screen reader.
| dpcx wrote:
| This looks like what web developers have been waiting literally
| decades for. Possibly replacing (eventually) a bunch of JS
| libraries to make this all do what we want.
|
| I don't have Chrome installed, but I'm curious how it handles
| multi-select fields, as I didn't see that in the example video.
| dqv wrote:
| I just tried it in the Codepen and it reverts to a regular old
| UI element when it has the multiple attribute.
|
| Also just tried it with multiple="multiple" just in case. Same
| behavior.
| zachrip wrote:
| That really sucks :/
| no_wizard wrote:
| Huge miss in my opinion. If it doesn't support all scenarios
| I'm not sure what the Chrome team is thinking here
| dqv wrote:
| I was just wondering how people do a custom <select
| multiple> now. I guess they make it screen-reader-only and
| then have aria-hidden checkboxes for everyone else.
| sureIy wrote:
| "Select multiple" is just a list of checkboxes. The
| missing part (which is also missing from select) is just
| the filtering.
|
| I am not holding my breath for a decent "select multiple"
| field. It's been the same crap for decades and browsers
| could have fixed it long again without waiting for spec -
| it's just a "replaced element", but they don't care.
|
| The fun part is that it looks amazing on Safari iOS (and
| QED it's rendered as a list of checkboxes)
| TimTheTinker wrote:
| > "Select multiple" is just a list of checkboxes.
|
| Not necessarily. I've seen more than one production app
| with a custom filtering dropdown list of items with
| checkboxes.
|
| I built a couple variants of that in React at my last gig
| for the company's design system. The keyboard nav was
| complex... that component is one of the work artifacts
| that I'm most proud of.
| sureIy wrote:
| > custom filtering dropdown
|
| I already said that. "Select" is not filterable in the
| browser already, so `select[multiple]` has no chance of
| seeing that in this decade.
|
| However you slice/style it, it's just checkboxes (that
| you can filter/reorder)
| mjrpes wrote:
| I commented on this a few weeks ago. There are two future
| components under development that look to support
| selecting multiple options in a dropdown format.
|
| Search textbox: would be supported under the 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/
| pests wrote:
| Incremental improvement?
|
| Why release anything right?
| no_wizard wrote:
| Incremental improvement is great, but I do want to know
| what they're thinking here.
|
| They didn't mention it in the blog post that multiple
| isn't supported. Its perfectly fine if it is _not_
| supported right now. It would be great if they
| acknowledged that up front to set expectations
| accordingly.
|
| For instance, if its explicitly not supported, then I
| won't be left wondering if its a bug or a
| misunderstanding of the implementation etc.
|
| Communication would be really good here. I'm all for
| incremental improvement, I think we need _more_ of it.
|
| Doesn't mean there shouldn't be better communication
| about it.
| pests wrote:
| In the original dev blog from last year they mention it's
| still a work in progress.
|
| https://developer.chrome.com/blog/rfc-customizable-select
|
| > Note: The multiple and size attributes on select
| (<select multiple> and <select size=n>) are not supported
| in appearance: base-select yet.
| no_wizard wrote:
| From _last year_ while it was a WIP
|
| and now this as of Chrome 135 is shipped, and they didn't
| think it wise to include a back reference to this post,
| calling out what isn't supported?
|
| They can and should communicate this is all.
| kelnos wrote:
| I expect they're thinking they should ship something that
| works, and covers some use cases, and gradually improve it
| over time to support more use cases.
|
| Y'know, like how most software development works.
| Contax wrote:
| > This looks like what web developers have been waiting
| literally decades for.
|
| Count me in. Most times it didn't matter to me but there were
| some cases when I wanted or needed them to have a specific
| style matching other elements and, yes, I could only do it -to
| the best I knew- with JS.
|
| Let's see if it becomes widely supported.
| oliv__ wrote:
| Oh my god. This has got to be like 20 years in the making
| rbrownmh wrote:
| I'd love to know the opportunity cost - billions?
| alabastervlog wrote:
| The cost of browsers not having extremely-basic things that
| they either started to implement then abandoned in a nigh-
| useless state (login, frames) or never even tried to have but
| really, _really_ should have once it was clear "web apps"
| were here to stay (datasource-backed lists and tables, table
| sorting without more custom JS than a sort function, drag-n-
| drop) is truly enormous. Who knows how many millions of
| person-hours.
| johnthuss wrote:
| Finally! This is incredibly good news. I hope the adoption of
| this feature is fast - looking at you Safari.
| jillyboel wrote:
| Can someone explain why this took them literal decades to do?
| Nesco wrote:
| There is no one truly in charge, it's a distributed standard
| LoganDark wrote:
| Priorities? Profit incentives?
| NoMoreNicksLeft wrote:
| As I remember the arguments from 20 years ago, there was strong
| pushback against changing any form inputs, which the people who
| did such work said should appear as the operating system itself
| styled them (so users would recognize them as form inputs).
|
| Should be able to style more than just selects, after all. Why
| the fuck can't I change the mask character in a password field
| to be something other than bullets? Hah. I had better examples
| too, but it looks like in the past 10 years or so, they've
| slowly been CSS-ized. Nice. Now if I could just style half the
| first line (first-line does the entirety of the line or
| nothing).
| codedokode wrote:
| Because HTML historically was designed for marking up text
| articles by hand rather than building UI with tools.
| klabb3 wrote:
| Better than broken JS libs but my main concern is the layouting
| yank, when there are many options and how to reach them without
| accidentally closing the select.
|
| > It doesn't trigger built-in mobile operating system components.
|
| Yeah so this is scary, but how is layouting done then?
|
| > Shown options positioned with anchor().
|
| Ok, also experimental, but maybe this is the best part of all?
| Floating UI? It's become a reusable thing with JS, it would be
| amazing if it was in CSS and actually worked.
| pests wrote:
| >> It doesn't trigger built-in mobile operating system
| components.
|
| >Yeah so this is scary, but how is layouting done then?
|
| Via HTML in-website, not via opening the android wheel picker
| or anything like that.
| wg0 wrote:
| First time I had the idea of building UI for apps using web
| technologies was in 2009 I suppose. These were the times of
| MFC/ATL/WinForms/GTK etc.
|
| Since then my faith in Web technologies for building UI for most
| apps keeps increasing.
|
| Through pure evolution - it's the most beautiful and open
| platform that's most cross platform.
| nasso_dev wrote:
| > It doesn't trigger built-in mobile operating system components.
|
| I worry about this. The built-in mobile operating system
| components are reliable, accessible, and responsive. I really
| like it when an input element opens the Android UI because I know
| how it works and that it is reliable. This applies to <select>,
| but also date/time inputs for example.
| gruez wrote:
| Chrome already uses plenty of non-native components. Firefox is
| similar. Moreover while I can understand the concern about
| poorly implemented components from random web developers,
| Google is probably the best positioned to implement a widget
| that faithfully replicates the native equivalent, at least on
| Android.
| asddubs wrote:
| you're misunderstanding, this will leave the appearance of
| the select on mobile up to the web developer
| johannes1234321 wrote:
| > Chrome already uses plenty of non-native components.
| Firefox is similar.
|
| This is then won't be consistent with native OS apps, but
| still be consistent across websites. Better than everybody
| doing different div+JavaScript magic which behaves slightly
| different across different websites.
| dimal wrote:
| This is only if you opt in to base-select, so if you don't use
| that, everything should continue to work the same, as far as I
| can tell.
| Macha wrote:
| "You" in this case is the website author. From a user
| perspective, that doesn't solve the problem.
| Onavo wrote:
| Can we have a fully native combobox now?
| breadwinner wrote:
| This is badly needed. Until we have combobox, the <select> is
| best implemented as a readonly combobox, because you need to
| implement combobox in any case.
| chias wrote:
| The <select> element can now be customized with CSS *in Chromium
| browsers*
| silverwind wrote:
| So at least 5 more years until in can actually be used.
| pier25 wrote:
| At least...
| indie_architect wrote:
| Can't wait to use it in 2030 when my work stops supporting IE11
| zb3 wrote:
| Developers, don't fall for this!
|
| This web API scope creep makes it __harder__ to create and
| maintain truly independent web browsers.. you have to implement
| more and more and eventually we arrive at the current state of
| matters - all non-chromium engines are lagging behind.
|
| Developers will happily use this, then users will notice websites
| "look better" in chrome and firefox will become even less
| relevant. Don't.. you can already achieve this without relying on
| chromium-only APIs.
| gjsman-1000 wrote:
| > and firefox will become even less relevant
|
| No; Firefox can easily afford financially to add this feature.
| Firefox is already irrelevant; no developer will shed a tear
| about just blocking Firefox if they refuse to implement.
| Boycotting won't work either, because boycotts almost never
| work.
| misiek08 wrote:
| > Firefox is already irrelevant
|
| Did I miss anything?
|
| It's still not as clumsy and resource intensive (while
| destroying hardware like disks) like Chrome..
| kelnos wrote:
| GP means irrelevant in the sense that Firefox's market
| share is so low that web devs need not test on it or ensure
| compatibility.
|
| This saddens me, as a Firefox user, but we have Mozilla's
| inept management to blame for this.
| codedokode wrote:
| Firefox doesn't have ad measurement and interests sharing
| built in yet (or am I wrong?) so it is very relevant for me.
| I would rather use black-and-white selects everywhere rather
| than having an advertising engine built into the browser.
| wolframhempel wrote:
| The fact that I'm disproportionally excited about this probably
| dates me as an early 2000s web developer. But since selects can
| do things that you simply cannot recreate in HTML, e.g. have
| options drop downs that extend outside the viewport boundaries,
| makes this a really helpful feature.
|
| Now, do autocompletes and tag selectors next...
| majora2007 wrote:
| It's actually crazy that we don't have a basic typeahead
| component or tag selector in this day and age with HTML. Every
| web page I've ever built has needed these components and while
| there are libraries out there, they all have an annoying bug
| here or there.
|
| But considering we are just now getting Select tags with
| styling, signals how long it might take for a typeahead which
| is vastly more complex.
| jhardy54 wrote:
| > basic typeahead
|
| It isn't perfect, but have you tried <datalist>?
|
| Totally agree about tag pickers, I was bummed to see that
| Bootstrap didn't have a tag selector component either.
| mlhpdx wrote:
| I have, and failed.
|
| See https://news.ycombinator.com/item?id=40265782
| recursive wrote:
| Safari is the "new" IE. I put "new" in quotes because
| it's been this way for like a decade.
| facile3232 wrote:
| If anything _chrome_ is the engine with odd quirks you
| are forced to work around.
| recursive wrote:
| I haven't found this to be the case in my experience.
| facile3232 wrote:
| Maybe it's just iframes that are the issue but they were
| a devil and a half to get working in chrome (or blink ig)
| without relying on third party cookies.
| progmetaldev wrote:
| Interested in what you are doing with the iframes.
| Something with complex authentication? I've been forced
| to use iframes a few times for 3rd party resources that
| should have been first-party (mostly with banks and
| credit unions), and have only had some styling issues on
| mobile (which have been overcome by using JavaScript and
| window.matchMedia to check for media queries).
| troupo wrote:
| --- start quote ---
|
| Back fifteen years ago IE held back the web because web
| developers had to cater to its outdated technology stack.
| "Best viewed with IE" and all that. But do you ever see a
| "Best viewed with Safari" notice? No, you don't. Another
| browser takes that special place in web developers'
| hearts and minds.
|
| --- end quote ---
|
| https://www.quirksmode.org/blog/archives/2021/08/breaking
| _th...
| recursive wrote:
| Yes, Safari is not exactly like IE because IE had a
| dominant user share once upon a time.
|
| We don't see "best viewed in Safari", but we do see
| plenty of sites that _can_ be viewed in Safari, despite
| the extra effort used to get them there. And I 'm not
| even a regular chrome user.
| ricenews wrote:
| It may not be present in Apple's official documentation
| but it has been supported since Safari 12.2.
|
| See https://developer.mozilla.org/en-
| US/docs/Web/HTML/Element/da... compatibility. The demo on
| that page works for me in current Safari on both iOS and
| Mac.
| asddubs wrote:
| also drag and drop rearrange
| renerick wrote:
| > have options drop downs that extend outside the viewport
| boundaries
|
| Unless this is about something different from what you mean,
| unfortunately, it's not the case, as stated in the article:
|
| > Using base-select loses a number of features and behaviors:
|
| > The <select> doesn't render outside the browser pane.
| asddubs wrote:
| I doubt it'll still be able to do those things. From the
| article:
|
| >Using base-select loses a number of features and behaviors:
|
| > The <select> doesn't render outside the browser pane.
|
| > It doesn't trigger built-in mobile operating system
| components.
|
| I have mixed feelings about it. Mobile users, get ready for
| poorly optimized select elements. On the other hand it reduces
| the need for javascript for styling forms, which is good
| wolframhempel wrote:
| That's fair, but I assume that is the initial implementation.
| Surely, over time, browser vendors will want to make the full
| spectrum of select functionality available consistently.
| caesil wrote:
| I don't think browsers will ever let web code affect things
| outside the viewport because scammers would cook up some
| truly zany things with that power.
| dbbk wrote:
| Definitely not. Why would they let web devs render outside
| of the browser window? That's a recipe for disaster.
| cush wrote:
| There needs to be some middle ground. I'd trade off just
| being able to set just the background color and font and
| keep these native-like features
| maccard wrote:
| If that's all your changing, then why can't you make do
| with the system default?
| Eric_WVGG wrote:
| "It doesn't trigger built-in mobile operating system
| components." Is that part of the spec? I can see Apple
| deviating from that implementation.
| jraph wrote:
| I'm not sure about this. It could break the positioning /
| sizing / box CSS properties.
|
| That would require rendering arbitrary HTML in the native
| widget, outside the browser. And I think _that_ would
| require putting WebKit in the native widget. Or, to
| maintain a "copy" of the widget that looks like the native
| one but uses WebKit to render things. Seems annoying to
| maintain.
|
| (And there are the security concerns mentioned by the other
| comments)
| cush wrote:
| > The <select> doesn't render outside the browser pane. ...
| It doesn't trigger built-in mobile operating system
| components.
|
| To me, this is intrinsically what makes a <select> a
| <select>. Styling is great, but without these features, this
| doesn't really bring anything new to the table
| tadfisher wrote:
| Thanks to humanity, supporting this is a surefire ticket to
| someone figuring out how to phish credentials through a
| <select> element.
| kmeisthax wrote:
| For the record, there's already a bunch of custom select-a-
| like replacement elements out there; I'm partial to select2.
| The main reason for this is that selects don't come with what
| we used to call "combobox" features; there's no type-ahead
| completion, and you can't lazy-load options from a larger
| data source because of that.
|
| My main gripe is the loss of rendering outside the browser
| pane. To be clear, we already don't have that on mobile at
| all; if you've ever used an iPad with Stage Manager you'll
| note how popovers - all of them, including native apps - are
| neatly conformed to the bounds of the containing window. Pop-
| over menus are _supposed_ to break the window pane, but they
| don 't, for reasons I don't quite understand but can guess
| rhyme with the word "security".
| preisschild wrote:
| <input type="datetime-local"> with automatic ISO8601 timezone
| offsets would be awesome too!
| sublinear wrote:
| ISO-8601 is not the correct format for serializing local time
| unless it's in the past.
|
| In my experience, a local datetime picker is going to be used
| almost exclusively for a future date and time. What you want
| instead of a timezone offset is a zone ID. That way date and
| tzdata can handle it properly on the backend.
| progmetaldev wrote:
| For this case, I will often ask for the timezone, since
| that data is often updated on the operating system, but I
| don't believe it's often for someone to be in the same
| location and have their timezone change. The software that
| I've maintained the most over the years (since 2009 up to
| deploying an update today) requires a login, so I have a
| client account that includes choosing their timezone. I
| then use that to convert everything to UTC in the database,
| and when I retrieve the data, I use it to convert UTC back
| to their local date/time. I felt that it was the best
| option, since a user moving to a different timezone should
| still be able to get dates/times back relative to where
| they have their current timezone set.
| kkarpkkarp wrote:
| > Now, do autocompletes
|
| This is kind of ready, see datalist element.
|
| https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...
| blatantly wrote:
| Ooh I can render arbitrary pixels outside the viewpoint. Like a
| system dialog asking for a password.
| sleepybrett wrote:
| hey, this is about 20 years late.
| butz wrote:
| Some controls are better left unstyled. Look what happened to
| scrollbars: either they are too thin to grab, have bad color
| contrast, so it is hard to see what part to actually grab, and,
| finally, some smartypants have managed even to remove scrollbars
| altogether from their website. Sure, default select is not the
| prettiest control, but it gets it job done.
| streptomycin wrote:
| Unfortunately those unusably small or invisible scrollbars are
| the default in many browsers. Such as Firefox on Linux, which
| I'm using right now.
| lblume wrote:
| I think this really comes down to personal preference. I also
| use Firefox on Linux and always find the Windows-type
| scrollbar to be incredibly ugly and bulky, especially on
| other overflow: scroll elements.
| layer8 wrote:
| Luckily Firefox allows changing that default.
| crazygringo wrote:
| This is more about rich HTML for the select options. Being able
| to select images, rows with two columns of information, extra
| information in a contrasting font weight, etc. This will be
| extremely helpful.
| SoftTalker wrote:
| Unlikely. Things need to be simple and consistent. The web is
| already a disaster on both of those factors and has been for
| a long time.
| crazygringo wrote:
| No, things need to communicate the required information for
| the task at hand.
|
| Limiting information can be harmful in many cases, and make
| things more difficult rather than simpler. And consistency
| can similarly limit usability.
|
| What if I want to select one of 10 colors, with limited
| screen space? Isn't a select with color swatches perfect?
| Or even better, color swatches with color names beside? Why
| do you think that should be limited to plaintext only?
| That's anti-user.
| SoftTalker wrote:
| Good example. There are dozens, maybe hundreds of
| different ways people have invented color pickers. Every
| app does it a little differently, meaning you have to
| stop and think about it every time. I'll take a simple
| select with the color name. If you want a swatch, put
| that off to the side and update it with an event handler
| on the select.
| crazygringo wrote:
| Names don't fully communicate color. There are hundreds
| of reds. Hundreds of greens.
|
| I don't want to have to click each green to see the
| swatch. Just put them in a list with swatches. That is
| obviously the easier UX. Nobody has to stop and think
| about anything.
| nickelpro wrote:
| That's objectively worse, there's no way to know what
| "blue" means in such a context, there are many blues.
|
| "I want things to be worse" is not a compelling argument.
| Letting developers describe the needs of their
| applications with a consistent grammar is not unnecessary
| invention, complexity, or friction.
|
| The grammars of a technology, the set of building blocks
| with which developers are empowered to create, should
| balance flexibility with expressive intent. CSS <select>
| strikes this balance nicely. To decry its inclusion says
| more about the naysayer than the feature.
| 65 wrote:
| I disagree. On my website I have a sidebar and a main content
| area. You are able to scroll through posts on the sidebar and
| through the content on the main content area. The sidebar is a
| dark color. Being able to use a thin sidebar and make the color
| of the sidebar dark to match the background makes the website
| look a lot better than having a clunky white sidebar on a dark
| background.
|
| The user can still obviously see the sidebar and knows its a
| sidebar, it just works better with the design.
| KTibow wrote:
| Ideally web browsers would use better defaults so you
| wouldn't have to do this. Firefox is good with this in my
| opinion: scrollbars are very subtle, don't affect content
| width, and adapt to the `color-scheme`.
| dimal wrote:
| This ship sailed in 2000. We've been hacking custom select
| boxes since then, so we may as well pave the cowpath. And
| besides, as a user, I want stylable select elements. Seeing an
| ugly old select box in the middle of a site where everything is
| styled consistently is jarring.
|
| And it doesn't get the job done. You can't put stuff like SVGs
| or complex DOM elements in them, which is a valid use case.
| Most of the time, when people create custom select boxes, they
| ignore accessibility. This will fix that issue.
| montag wrote:
| I may not agree with your ugly scrollbars, but I will defend
| your right to style them.
|
| (If you want to annoy your users, that's your prerogative)
| johnfn wrote:
| Now how do I add an text input filter? Is that another 20 year
| wait? :-)
| ichik wrote:
| Looks pretty broken in FF 136.0.2 (missing backgrounds/boxes, the
| popoup menus are visible).
| rsingel wrote:
| Oh the irony of the Chrome dev blog failing Google's own Core Web
| Vitals test
|
| https://developer.chrome.com/blog/a-customizable-select
| dmvjs wrote:
| in Chrome :wince: I honestly wish they didn't add this
| hk1337 wrote:
| meh. it looks really nice but I would rather do the basic styling
| I can do now for the 99% of the times where I don't really need
| it.
|
| I have said it before, everyone (Developers that use Chrome
| almost exclusively) says Safari is the new IE but Chrome has been
| slowing becoming the thing they fought against since they
| defeated IE.
| Brysonbw wrote:
| Been waiting for this - hopefully this inspires more native web
| features to be implemented so devs can reduce their reliance on
| dependencies
| cellover wrote:
| Love the fact that Google auto translate of the page completely
| breaks the page
|
| https://imgur.com/7gfXRrm
| nedt wrote:
| This is also very much how the page looks for me in Firefox. If
| it can't fail without issues it's not an option I'd select.
| nedt wrote:
| Oh ... it's actually their own integrated translation that
| breaks it. Now that's funny. They aren't escaping correctly.
| Now if someone wants to play around with that ...
| ruined wrote:
| firefox issue
| https://bugzilla.mozilla.org/show_bug.cgi?id=1944403
| tracker1 wrote:
| Damn... been wanting this for well over two decades. About time.
| Still missing a good combo-box and type-ahead solution from the
| box.
| kelnos wrote:
| What I was recently disappointed to find out is that you can't
| have a separate "display name" for the option items. That is,
| when the user clicks and the dropdown opens, I want the item
| labels in the dropdown to be of the form "$TITLE
| ($SHORT_DESCRIPTION)", but then when the dropdown is closed and
| something is selected, the control should just read "$TITLE".
| There are a few hacks to sort of make that work, but they all
| have downsides that make them unusable for me. (The purpose for
| me was to make it so the <select> element doesn't take up as much
| horizontal space; most of the workarounds end up missing that
| quality.)
|
| There was one thing that I hoped would work, but didn't, which is
| applying an :after pseudo-class to <option>, so something like
| this: option:after { content: ' ('
| attr(data-descr) ')'; } <select>
| <option data-descr="some description">Foo</option>
| <option data-descr="some other stuff">Bar</option>
| </select>
|
| Unfortunately this just doesn't work (I presume because <option>
| can't contain DOM elements aside from unstyled text), but I
| wonder if it will work now.
| largehotcoffee wrote:
| Why would this be preferred over creating a new HTML element,
| like <options>?
| minitech wrote:
| Backwards compatibility. Older browsers will still be able to
| render the <select> and submit it as part of a form, just with
| its options unstyled.
| blatantly wrote:
| > Changes the browsers HTML parser
|
| Sounds like you can create loops. If the select had a style
| element that turns this off again would it keep changing state?
| pier25 wrote:
| So how long until Safari adopts this?
| ilayn wrote:
| Wow what's next, scrolling title text? What a time to be alive...
| darepublic wrote:
| trying to write automation js for material ui dropdowns has been
| a PITA. This is the right direction!!
| renegade-otter wrote:
| It's been 84 years...
| codedokode wrote:
| Making web standards even more complicated one change at a time.
| peteforde wrote:
| If they keep this up, we'll soon have feature parity with VB6.
___________________________________________________________________
(page generated 2025-03-31 23:00 UTC)