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...
asddubs 2 days ago [-]
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
cush 2 days ago [-]
> 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
wruza 2 days ago [-]
With these features scammers will create all sorts of "you have to log into your password manager" popups again.
tadfisher 2 days ago [-]
Thanks to humanity, supporting this is a surefire ticket to someone figuring out how to phish credentials through a <select> element.
cush 4 hours ago [-]
Certainly, there exists a middle ground between having no options for styling and some options where we don't compromise users
kmeisthax 2 days ago [-]
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".
Eric_WVGG 2 days ago [-]
"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 2 days ago [-]
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)
wolframhempel 2 days ago [-]
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 2 days ago [-]
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.
immibis 2 days ago [-]
Even rendering arbitrary pixels inside the viewport is bad enough. Something that went out of fashion but is apparently now back in fashion is detecting the user's operating system and browser, then displaying a pixel-perfect replica of a second browser window open to Paypal and asking you to log in... displayed within the bounds of the first browser window.
dbbk 2 days ago [-]
Definitely not. Why would they let web devs render outside of the browser window? That's a recipe for disaster.
cush 2 days ago [-]
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
eurleif 2 days ago [-]
The following works for me in Chrome, and doesn't prevent the menu from going outside of the viewport:
select, option {
background: red;
font-family: 'comic sans ms';
}
cush 1 days ago [-]
Yeah, it only works in Chrome
maccard 2 days ago [-]
If that's all your changing, then why can't you make do with the system default?
immibis 2 days ago [-]
Mobile users are the majority of users by far. Do web designers really make their sites hostile to most of their users? (I suspect the answer is yes)
qiqitori 2 days ago [-]
I think this totally depends on the site in question. Seriously researching something is hell on mobile browsers. As is doing productive stuff. Who wants to work on a tiny screen and no keyboard? On the desktop you can open dozens or hundreds of tabs on a single topic. Therefore I'm not surprised to see that on my site (technical articles) I can see the number of requests from mobile devices is just 17%.
Windows is 52%, Linux (without Android) is 18%, Macintosh is 13%, Android 11%, iOS 6%, Chrome OS 0.5%, others <0.5%. (Android and iOS may include tablets, but the overall traffic from tablets is just a few percent.) (Note that I've excluded crawlers and unknown user agents (bots and crawlers) from these results.)
FWIW, some bots lie about what they are, which typically inflates the Windows results. I have another source of data, I can see what types of devices saw my site in Google results, and it's 69% desktops, 30% mobile, 1% tablets. (I can also see how many clicked, and it's similar numbers.)
majora2007 2 days ago [-]
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.
cosmic_cheese 2 days ago [-]
Why implement broadly useful HTML widgets when you can instead put those engineering resources to work on a new WebBeer API that fetches the number of beers in the user’s fridge or something else similarly niche?
jhardy54 2 days ago [-]
> 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.
That demo shows the problems splendidly. It “only kinda” works on iOS.
no_wizard 2 days ago [-]
Some examples seem to work better than others though. I’m on latest iOS and sometimes it will invoke the native date picker like you’d expect to see, sometimes it won’t, and the type ahead doesn’t seem to work consistently
recursive 2 days ago [-]
Safari is the "new" IE. I put "new" in quotes because it's been this way for like a decade.
troupo 2 days ago [-]
--- 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.
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.
troupo 24 hours ago [-]
The absolute vast majority of web sites require no effort to "get there".
The absolute vast majority of those which don't work in Safari use Chrome-only non-standards.
And there is a tiny minority of sites that run into some Safari-specific quirks
facile3232 2 days ago [-]
If anything chrome is the engine with odd quirks you are forced to work around.
recursive 2 days ago [-]
I haven't found this to be the case in my experience.
facile3232 2 days ago [-]
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 2 days ago [-]
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).
immibis 2 days ago [-]
Chrome's quirks become the standard and other browsers have to implement them.
I know about datalist, but it's the saddest autocomplete experience you can offer. If something is not fully styleable, it's automatically garbage. If it's styleable, it may be decent.
Now, I understand why datalist is not styleable the way it is implemented right now. On Android, the suggestions come on the top bar of the native keyboard, so it doesn't make sense to be able to put arbitrary divs there. But in that case, there should be an alternative styleable autocomplete element.
Another element that is unstyleable crap is <input type=file>, <audio> too.
renerick 2 days ago [-]
> 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.
preisschild 2 days ago [-]
<input type="datetime-local"> with automatic ISO8601 timezone offsets would be awesome too!
sublinear 2 days ago [-]
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 2 days ago [-]
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.
mason55 1 days ago [-]
This works for things in the past but not things in the future.
If I say I want something to happen at 8pm New York City time on January 7, 2028 and then the DST rules for NYC change, I likely still want it to happen at 8pm. Converting to UTC and back to local time loses that information and it will happen at the wrong time.
ibejoeb 2 days ago [-]
Right. The offset is not enough without a reference recorded time. You need the time and the time zone in order know the true time. This is a big problem is systems that don't have an intrinsic time type that deploy and have a database full of ambiguous times. Once it happens, backfilling that is a real slog.
blatantly 2 days ago [-]
Ooh I can render arbitrary pixels outside the viewpoint. Like a system dialog asking for a password.
ljoshua 2 days ago [-]
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. :)
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 2 days ago [-]
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 2 days ago [-]
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 2 days ago [-]
> 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:
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 2 days ago [-]
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.
JimDabell 2 days ago [-]
> 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.
You can use popovers like this without JavaScript:
You can mark a <dialog> element as open by default with the `open` attribute, and you can close it with a button using the `dialog` form method. No JavaScript required for that either.
I don’t think there’s any way at present to open a `<dialog>` element specifically without JavaScript, but command/commandfor handles this and was recently added to the HTML specification:
// For opening
<button onclick='document.querySelector("#dialogId").showModal()'>Open</button>
// For closing
<button onclick='this.closest("dialog").close()'>Close</button>
I think the problem here is that it is impossible to actually use the result from `close()`, as it can return a status, IIRC.
> It would just make so much sense.
That way above that I propose is about as sensible as the way you propose. If there are any problems with my proposal that are solved by your proposal, I'd love to hear it.
If you need to worry about ADA compliance (I always do, but not always paid to), this can be difficult to address.
I remember Opera, before it was bought, had the best support for html5 elements and date/time inputs were the best (along with almost all others). Sad to think that a leader in this area was sold off, and not to a buyer that cared about usability and the web the way Opera did.
codedokode 2 days ago [-]
You can't make enough HTML elements to make everyone happy. This was the wrong idea from the start.
spartanatreyu 2 days ago [-]
The solution isn't to make a new html element for each use case.
The solution is to make html elements extensible.
With the `appearance: base-select` css rule, we now have a standardized way to extend <select> with html and css, (and we have the potential to declaratively extend intractability too with invoking commands without needing to reach for JS)
owebmaster 2 days ago [-]
> The solution is to make html elements extensible.
I would argue you can make enough HTML elements to make enough people happy. 80% for the 80%.
hombre_fatal 2 days ago [-]
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.
2 days ago [-]
ksec 2 days ago [-]
Over TWO decades late.
It is crazy to think what we only just have in anything non JavaScript in the past 20 years.
Cthulhu_ 1 days ago [-]
It's like how border-radius was added after rounded corners via images fell out of fashion.
true_religion 2 days ago [-]
I somehow feel Safari drags its feet on basic things platform improvements because they want to focus on iOS apps instead.
alwillis 2 days ago [-]
The narrative Safari is behind and Apple doesn’t care about the web is so tired…
This 8,000+ word article on Safari 18.4 (released today, BTW) doesn’t read like an organization that doesn’t care about the web [1].
I don’t want to debate if a mega corp cares or not, but compared to how UI frameworks were in the 90s, the developer experience is anemic.
I don’t know if HTML, CSS and JavaScript are the best path forward. Maybe they are doing exactly what their spec set out to do.
But we need something better that doesn’t leash one to an ecosystem that takes 30% of your revenue.
yujohn 2 days ago [-]
[dead]
arp242 2 days ago [-]
Eh; the standard is two weeks old. Written by someone working for Apple by the way.
true_religion 1 days ago [-]
I’m wondering where in my comment it sounded like I wanted this standard specially to be implemented yesterday?
paddy_m 2 days ago [-]
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.
no_wizard 2 days ago [-]
The perpetual 5 year problem of web development. I wish there was a way to do forward standards
bsimpson 2 days ago [-]
> 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.
klysm 1 days ago [-]
This might be a bad take, but I think developers should also consider exactly which users are using their app. If it’s the entire internet, then absolutely you need to consider backwards compatibility. If it’s an internal app, then consider not caring and using new APIs.
simiones 2 days ago [-]
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.
nasso_dev 2 days ago [-]
> 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.
dimal 2 days ago [-]
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 2 days ago [-]
"You" in this case is the website author. From a user perspective, that doesn't solve the problem.
gruez 2 days ago [-]
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.
johannes1234321 2 days ago [-]
> 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.
asddubs 2 days ago [-]
you're misunderstanding, this will leave the appearance of the select on mobile up to the web developer
butz 2 days ago [-]
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.
dimal 2 days ago [-]
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.
65 2 days ago [-]
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 2 days ago [-]
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`.
crazygringo 2 days ago [-]
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 2 days ago [-]
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 2 days ago [-]
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 2 days ago [-]
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.
nickelpro 2 days ago [-]
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.
crazygringo 2 days ago [-]
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.
immibis 2 days ago [-]
Windows had a standard color picker dialog that you may remember from Windows 98-Viata mspaint.
Jack of all trades, master of none. The mspaint-specific palette toolbar was much more intuitive.
userbinator 2 days ago [-]
managed even to remove scrollbars altogether from their website
What's worse are the custom JS ones that only appear on hover, obscuring the contents partially where they happen to be, and then when you try to drag them and accidentally move the pointer just a tiny bit off their skinny width, they disappear and you end up accidentally activating whatever element happens to be underneath.
streptomycin 2 days ago [-]
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 2 days ago [-]
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.
BrenBarn 2 days ago [-]
Exactly. It's personal preference, which means it should be the user's choice, not the site designer's.
layer8 2 days ago [-]
Luckily Firefox allows changing that default.
montag 2 days ago [-]
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)
dpcx 2 days ago [-]
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 2 days ago [-]
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.
no_wizard 2 days ago [-]
Huge miss in my opinion. If it doesn’t support all scenarios I’m not sure what the Chrome team is thinking here
kelnos 2 days ago [-]
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.
8n4vidtmkvmk 2 days ago [-]
They've screwed this up several times by shipping too soon and then having to backpedal. The web is not something you want to screw up because they don't own every website in existence.
dqv 2 days ago [-]
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 2 days ago [-]
"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)
mjrpes 2 days ago [-]
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
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 2 days ago [-]
> 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)
pests 2 days ago [-]
Incremental improvement?
Why release anything right?
no_wizard 2 days ago [-]
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 2 days ago [-]
In the original dev blog from last year they mention it’s still a work in progress.
> Note: The multiple and size attributes on select (<select multiple> and <select size=n>) are not supported in appearance: base-select yet.
no_wizard 2 days ago [-]
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.
pests 2 days ago [-]
Agreed. Should have mentioned it in this post or at least linked back to my source.
zachrip 2 days ago [-]
That really sucks :/
Contax 2 days ago [-]
> 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.
chias 2 days ago [-]
The <select> element can now be customized with CSS *in Chromium browsers*
robin_reala 2 days ago [-]
It’s the web equivalent of the Twitter account that added “in mice” to medical headlines. Nice in theory, but it’ll take years before it’s usable and in all likelihood it’s just another experiment that’ll never go anywhere.
silverwind 2 days ago [-]
So at least 5 more years until in can actually be used.
At least Safari is failing as well, currently, so the FF team has a bit of time.
tracker1 2 days ago [-]
Damn... been wanting this for well over two decades. About time. Still missing a good combo-box and type-ahead solution from the box.
klabb3 2 days ago [-]
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 2 days ago [-]
>> 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.
Onavo 2 days ago [-]
Can we have a fully native combobox now?
breadwinner 2 days ago [-]
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.
codedokode 2 days ago [-]
Making web standards even more complicated one change at a time.
earcar 1 days ago [-]
Fascinating timing for this feature. I suspect the AI chatbot explosion has been a major driver behind the push for richer select elements.
Have you noticed how every AI interface needs to let you choose between models? The current select element is embarrassingly inadequate when you need to show more than just text labels. You want to display model capabilities, performance indicators, context sizes - not just "GPT-4" vs "Claude 3.7" as plain text.
johnthuss 2 days ago [-]
Finally! This is incredibly good news. I hope the adoption of this feature is fast - looking at you Safari.
ichik 2 days ago [-]
Looks pretty broken in FF 136.0.2 (missing backgrounds/boxes, the popoup menus are visible).
peteforde 2 days ago [-]
If they keep this up, we'll soon have feature parity with VB6.
cellover 2 days ago [-]
Love the fact that Google auto translate of the page completely breaks the page
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 2 days ago [-]
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 ...
efilife 2 days ago [-]
what's to love about this?
2 days ago [-]
paradox460 1 days ago [-]
I still wish it would grow some primitive filtering/searching feature. I'm very tired of having to reach for JavaScript just to let users narrow a massive list of things
hbroadbent 1 days ago [-]
Hey! Actually that is possible using the <datalist> element.
Why would this be preferred over creating a new HTML element, like <options>?
minitech 2 days ago [-]
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.
kelnos 2 days ago [-]
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:
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.
spartanatreyu 2 days ago [-]
`attr()` has had terrible support which is a shame because it's been around for ages and could have let us do a lot of things without having to implement stuff manually.
There's another way to try it though...
I'd try putting two separate <span>s inside each option, one for the short description and one for the long description.
I'd hide one span with css if it was inside an <option> tag.
I'd hide the other span if it was inside a <selectedoption> tag.
That would probably work.
The papercut would be that when gracefully degrading back to an ordinary select element, it might show both the short and the long selections which depending on how you write the content may or may not be an issue.
zerocrates 2 days ago [-]
Ignoring this new feature, you can't put spans inside an option, only text. It's odd that they have this example in the post for the "old" way but they show it retaining the spans.
spartanatreyu 21 hours ago [-]
You can put <span>s inside an <option>. The <option>'s `innerText` is used to populate the native control's label, meaning the inside of the spans are too.
The problem is that you can't target the span in the original parser.
But, you could use a template, since it's contents are ignored by text content parsers.
You can have your option as:
<option value="red">
<span>Normal Difficulty</span>
<template>- The way it's meant to be played</template>
</option>
With the original parser, this will be parsed as:
<option value="red">Normal Difficulty</option>
And with the new parser (so long as you opt into it with the `appearance: base-select` rule):
<option value="red">
<span>Normal Difficulty</span>
<template>- The way it's meant to be played</template>
</option>
---------------------------
Then once you've opted into the new parser, you can target both the span and template to render how you want. (e.g. Give span a larger font-weight, give template a display mode of block and italicised text)
zerocrates 5 minutes ago [-]
Sure you can do it with this new feature.
I assumed your comment was trying to give the parent commenter a strategy that would work with the "classic" select but I see now that you mentioned "selectedoption" so you were talking about the new one.
AbuAssar 2 days ago [-]
There should be a search box by default at the top of any <select> dropdown if there are more than n items
blatantly 2 days ago [-]
> 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?
vntok 1 days ago [-]
I don't see how it would create a loop? It seems like the parser change only impacts <select>'s descendant elements (to stop "cleaning" them of illegal elements), not <select> itself.
jillyboel 2 days ago [-]
Can someone explain why this took them literal decades to do?
NoMoreNicksLeft 2 days ago [-]
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).
Nesco 2 days ago [-]
There is no one truly in charge, it's a distributed standard
codedokode 2 days ago [-]
Because HTML historically was designed for marking up text articles by hand rather than building UI with tools.
LoganDark 2 days ago [-]
Priorities? Profit incentives?
Brysonbw 2 days ago [-]
Been waiting for this - hopefully this inspires more native web features to be implemented so devs can reduce their reliance on dependencies
ilayn 2 days ago [-]
Wow what's next, scrolling title text? What a time to be alive...
darepublic 2 days ago [-]
trying to write automation js for material ui dropdowns has been a PITA. This is the right direction!!
pier25 2 days ago [-]
So how long until Safari adopts this?
sleepybrett 2 days ago [-]
hey, this is about 20 years late.
renegade-otter 2 days ago [-]
It's been 84 years...
hk1337 2 days ago [-]
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.
jeffhuys 1 days ago [-]
I'm sitting here for a few years already, happily using Safari as my main driver. Recently switched to Orion to get Safari + Chrome/FF plugins. Best combination.
Easy on the battery, freaking fast, low ram usage, and plugin support (ALSO on iOS, yes, uBlock on iOS). Screw firefox, screw chrome.
Yes, I also dev on Orion. The dev tools are fine.
hk1337 1 days ago [-]
One of the main features I love about Safari is that in private browsing mode, the tabs (at least) appear to be completely isolated.
If I go to Facebook and login in one tab, then open a second tab and go Facebook, it doesn't recognize that I have logged in. There's moments where that is annoying but most of the time it's useful.
jeffhuys 1 days ago [-]
Yeah they are, which is IMO a good thing but it'd be better if you could link them somehow, maybe have a temporary session or something.
oliv__ 2 days ago [-]
Oh my god. This has got to be like 20 years in the making
rbrownmh 2 days ago [-]
I'd love to know the opportunity cost - billions?
alabastervlog 2 days ago [-]
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.
johnfn 2 days ago [-]
Now how do I add an text input filter? Is that another 20 year wait? :-)
sbussard 1 days ago [-]
Great! Now what about webtransport in WebKit?
BrenBarn 2 days ago [-]
Oh joy. Another way for website designers to override user display preferences.
vntok 1 days ago [-]
On the contrary. It's CSS, you can change all of this in your browser's CSS overrides if you want.
T3RMINATED 2 days ago [-]
[dead]
dmvjs 2 days ago [-]
in Chrome :wince: I honestly wish they didn't add this
wg0 2 days ago [-]
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.
zb3 2 days ago [-]
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 2 days ago [-]
> 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 2 days ago [-]
> 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 2 days ago [-]
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 2 days ago [-]
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.
That is disappointing. I went into settings to turn this off but it is already turned off and I don't remember whether I did it or my distribution ships Firefox with non-recommended settings. I hope it is the latter so that I don't get disappointed in Linux distributions also.
Now, do autocompletes and tag selectors next...
>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
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
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".
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)
Windows is 52%, Linux (without Android) is 18%, Macintosh is 13%, Android 11%, iOS 6%, Chrome OS 0.5%, others <0.5%. (Android and iOS may include tablets, but the overall traffic from tablets is just a few percent.) (Note that I've excluded crawlers and unknown user agents (bots and crawlers) from these results.)
FWIW, some bots lie about what they are, which typically inflates the Windows results. I have another source of data, I can see what types of devices saw my site in Google results, and it's 69% desktops, 30% mobile, 1% tablets. (I can also see how many clicked, and it's similar numbers.)
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.
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.
See https://news.ycombinator.com/item?id=40265782
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.
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...
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.
The absolute vast majority of those which don't work in Safari use Chrome-only non-standards.
And there is a tiny minority of sites that run into some Safari-specific quirks
This is kind of ready, see datalist element.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...
Now, I understand why datalist is not styleable the way it is implemented right now. On Android, the suggestions come on the top bar of the native keyboard, so it doesn't make sense to be able to put arbitrary divs there. But in that case, there should be an alternative styleable autocomplete element.
Another element that is unstyleable crap is <input type=file>, <audio> too.
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.
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.
If I say I want something to happen at 8pm New York City time on January 7, 2028 and then the DST rules for NYC change, I likely still want it to happen at 8pm. Converting to UTC and back to local time loses that information and it will happen at the wrong time.
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...
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
How are those half-baked? No smooth transition for details/summary, maybe?
Dialog seems to work well enough with little to no javascript required:
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.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.
You can use popovers like this without JavaScript:
You can mark a <dialog> element as open by default with the `open` attribute, and you can close it with a button using the `dialog` form method. No JavaScript required for that either.I don’t think there’s any way at present to open a `<dialog>` element specifically without JavaScript, but command/commandfor handles this and was recently added to the HTML specification:
https://github.com/whatwg/html/pull/9841
You can do this right now already:
I think the problem here is that it is impossible to actually use the result from `close()`, as it can return a status, IIRC.> It would just make so much sense.
That way above that I propose is about as sensible as the way you propose. If there are any problems with my proposal that are solved by your proposal, I'd love to hear it.
I remember Opera, before it was bought, had the best support for html5 elements and date/time inputs were the best (along with almost all others). Sad to think that a leader in this area was sold off, and not to a buyer that cared about usability and the web the way Opera did.
The solution is to make html elements extensible.
With the `appearance: base-select` css rule, we now have a standardized way to extend <select> with html and css, (and we have the potential to declaratively extend intractability too with invoking commands without needing to reach for JS)
The solution would be to make Apple ship this:
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
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.
It is crazy to think what we only just have in anything non JavaScript in the past 20 years.
This 8,000+ word article on Safari 18.4 (released today, BTW) doesn’t read like an organization that doesn’t care about the web [1].
[1]: https://webkit.org/blog/16574/webkit-features-in-safari-18-4...
I don’t want to debate if a mega corp cares or not, but compared to how UI frameworks were in the 90s, the developer experience is anemic.
I don’t know if HTML, CSS and JavaScript are the best path forward. Maybe they are doing exactly what their spec set out to do.
But we need something better that doesn’t leash one to an ecosystem that takes 30% of your revenue.
The days are long but the years are short.
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.
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.
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.
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.
The user can still obviously see the sidebar and knows its a sidebar, it just works better with the design.
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.
"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.
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.
Jack of all trades, master of none. The mspaint-specific palette toolbar was much more intuitive.
What's worse are the custom JS ones that only appear on hover, obscuring the contents partially where they happen to be, and then when you try to drag them and accidentally move the pointer just a tiny bit off their skinny width, they disappear and you end up accidentally activating whatever element happens to be underneath.
(If you want to annoy your users, that's your prerogative)
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.
Also just tried it with multiple="multiple" just in case. Same behavior.
Y'know, like how most software development works.
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)
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/
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.
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)
Why release anything right?
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.
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.
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.
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.
We're only waiting on Safari now: https://github.com/WebKit/standards-positions/issues/386
https://developer.chrome.com/blog/a-customizable-select
Last update to the issue is a pointer to test results:
https://wpt.fyi/results/html/semantics/forms/the-select-elem...
At least Safari is failing as well, currently, so the FF team has a bit of time.
> 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.
>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.
Have you noticed how every AI interface needs to let you choose between models? The current select element is embarrassingly inadequate when you need to show more than just text labels. You want to display model capabilities, performance indicators, context sizes - not just "GPT-4" vs "Claude 3.7" as plain text.
https://imgur.com/7gfXRrm
If you're interested, I wrote a bit more about it here: https://harrisonbroadbent.com/blog/cool-native-html-elements...
Styleable XOR Unusable = 1.
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:
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.There's another way to try it though...
I'd try putting two separate <span>s inside each option, one for the short description and one for the long description.
I'd hide one span with css if it was inside an <option> tag.
I'd hide the other span if it was inside a <selectedoption> tag.
That would probably work.
The papercut would be that when gracefully degrading back to an ordinary select element, it might show both the short and the long selections which depending on how you write the content may or may not be an issue.
The problem is that you can't target the span in the original parser.
But, you could use a template, since it's contents are ignored by text content parsers.
You can have your option as:
<option value="red"> <span>Normal Difficulty</span> <template>- The way it's meant to be played</template> </option>
With the original parser, this will be parsed as:
<option value="red">Normal Difficulty</option>
And with the new parser (so long as you opt into it with the `appearance: base-select` rule):
<option value="red"> <span>Normal Difficulty</span> <template>- The way it's meant to be played</template> </option>
---------------------------
Then once you've opted into the new parser, you can target both the span and template to render how you want. (e.g. Give span a larger font-weight, give template a display mode of block and italicised text)
I assumed your comment was trying to give the parent commenter a strategy that would work with the "classic" select but I see now that you mentioned "selectedoption" so you were talking about the new one.
Sounds like you can create loops. If the select had a style element that turns this off again would it keep changing state?
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).
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.
Easy on the battery, freaking fast, low ram usage, and plugin support (ALSO on iOS, yes, uBlock on iOS). Screw firefox, screw chrome.
Yes, I also dev on Orion. The dev tools are fine.
If I go to Facebook and login in one tab, then open a second tab and go Facebook, it doesn't recognize that I have logged in. There's moments where that is annoying but most of the time it's useful.
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.
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.
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.
Did I miss anything?
It’s still not as clumsy and resource intensive (while destroying hardware like disks) like Chrome..
This saddens me, as a Firefox user, but we have Mozilla's inept management to blame for this.
https://support.mozilla.org/en-US/kb/privacy-preserving-attr...
"Privacy preserving attribution" sounds like "money preserving robbery" (or money preserving tax).