6 ms·

CSS System Colors (2021)

jacobmarble 4y ago
Looks like support for "system colors" is up to 96% in 2023: https://caniuse.com/mdn-css_types_color_system-color https://caniuse.com/mdn-css_types_color_system-color
- chrisfinazzo 4y ago
  +10000 for the "lazy" Dark mode - it's excellent. Now if only I could find a use for #rebeccapurple again... a:hover, maybe??
  - eimrine 4y ago
    Are you sure that this color is supported in every browser your website is going to be visited? Why not write "#639" instead?
    - chownie 4y ago
      If the browser doesn't support rebeccapurple then there's a whole bunch of other features that also won't work.
    - chrisfinazzo 4y ago
      You could use the shorthand, but it's really not necessary at this point. The spec is (unsurprisingly) quite [specific][1] that this color value is exactly "#663399". All browsers which implement CSS Colors have had support for years now and the Color Module itself is now a CR as of a year and a half ago. Incompatibility isn't exactly a rounding error yet, but we're close. [1]: https://lists.w3.org/Archives/Public/www-style/2014Jun/0312.html https://lists.w3.org/Archives/Public/www-style/2014Jun/0312....
  - hanniabu 4y ago
    My lazy dark mode solution: html.dark-mode { filter: grayscale(100%) invert(100%); }
    - rawling 4y ago
      I had some fun inverting and then rotating the hue back around.
    - cubefox 4y ago
      This would also create negatives of pictures, right?
      - hanniabu 4y ago
        Correct. It's great for mostly text content or as a nice quick and dirty fix until you get around to creating a proper dark theme. Alternatively you can target elements individually, omitting images.
        cubefox 4y ago
        Perhaps there is some fancy selector which excludes images?
        extra88 4y ago
        If you use just invert(100%), no grayscale, on the body, you can add img { filter: invert(100%) } to reverse images back to their original color. However, if an image has any transparency or translucency, it may be harder to see with what the background color has become.
    - tomxor 4y ago
      I've used something to this effect before, and you can use child selectors on e.g images to effectively exclude elements. Note that the cost of this lazy method is very poor performance (css filter over the entire document), and lack of control over dark colours (inverted colours don't necessarily work best, shifting hue can help but you probably don't want the same as uninverted colours because they tend to be too dark and lack sufficient contrast).
- jrmg 4y ago
  That site seems to suggest it’s supported on Firefox as far back as Firefox 2 in 2006, which doesn’t really jibe with the article.
  - hrunt 4y ago
    The article points out that while system colors are supported in Firefox (as of the time of the writing of the article), the "color-scheme: light dark" method he was using was not supported, and it looks like that was not supported until Firefox 96 (January 2022).[0] [0] https://caniuse.com/mdn-css_properties_color-scheme https://caniuse.com/mdn-css_properties_color-scheme
    - Dalewyn 4y ago
      >until Firefox 96 (January 2022). Off topic, but the fact you felt a need to datestamp it indicates the Chrome Version Number System is bloody worthless.
- chrismorgan 4y ago
  This is misleading, and it would be nice if someone would correct it (after figuring out all the whats and whens). Its support table is for the CSS2 system colours, as defined back in 1997. <https://www.w3.org/TR/WD-CSS2-971104/ui.html#h-18.2 https://www.w3.org/TR/WD-CSS2-971104/ui.html#h-18.2> (Aside: “96.61%” is… well, for the type of browser they’re talking about—ones that support such things as CSS and colour—it should be exactly 100%, if not higher. Decide for yourself the sanity of this usage figure.) CSS Color Module Level 3 <https://www.w3.org/TR/css-color-3/#css2-system https://www.w3.org/TR/css-color-3/#css2-system> then deprecated them, for no good reason¹.² CSS Color Module Level 4 <https://www.w3.org/TR/css-color-4/#css-system-colors https://www.w3.org/TR/css-color-4/#css-system-colors> revived the concept of system colours, largely fixing the bad aspects and making it all clearly good. Some of the colours are still deprecated, with some at-risk³ dumbing-down. But there are also some new colours: Canvas and CanvasText. So the problem is that that MDN compatibility data is talking about CSS2 system colours, not CSS Color Module Level 4, which has much lower support (and may not all have been implemented at the same time: most were probably added around 2019, but some in 2021 and AccentColor and AccentColorText in 2022). Here are the actual colours, to help anyone who wants to update data (have fun identifying when they were added!): • New in CSS Color Module Level 4: AccentColor, AccentColorText, ActiveText, ButtonBorder, Canvas, CanvasText, Field, FieldText, LinkText, Mark, MarkText, SelectedItem, SelectedItemText, VisitedText. • Retained from CSS2: ButtonFace, ButtonText, GrayText, Highlight, HighlightText. • Deprecated from CSS2: ActiveBorder, ActiveCaption, AppWorkspace, Background, ButtonHighlight, ButtonShadow, CaptionText, InactiveBorder, InactiveCaption, InactiveCaptionText, InfoBackground, InfoText, Menu, MenuText, Scrollbar, ThreeDDarkShadow, ThreeDFace, ThreeDHighlight, ThreeDLightShadow, ThreeDShadow, Window, WindowFrame, WindowText. —⁂— ¹ Look, some of the system colours were clearly bad, modelling OS styles that were almost completely gone by this time. I suspect that some people didn’t like some of these too-specific values, and they threw the baby out with the bathwater. ² Earlier revisions mentioned the deprecation as being in favour of the ‘appearance’ property, but this was pretty stupid⁴ even when it was prospective, as first written, long before the ‘appearance’ property bit the dust for that time. ³ See <https://www.w3.org/TR/css-color-4/#deprecated-system-colors https://www.w3.org/TR/css-color-4/#deprecated-system-colors>: it defines fallback mappings that reduce the variations, but Firefox and Safari haven’t implemented the dumbing-down, still having the more-nuanced stuff they had from decades go. Hence “Results on these 'same as' equivalence tests are not great, which is why the feature is at-risk”. ⁴ No, seriously, just totally clueless and I have no idea what whoever wrote that was thinking, because it was always a completely different thing with only minimal potential overlap in uses.
- mixmastamyk 4y ago
  And the other almost 4% is "unknown" not specifically unsupported. Those browsers are unsupported ones from ancient Android releases.
hurrah4b4con 4y ago
[flagged]
- acallaghan 4y ago
  Alright but not sure what any of that has to do with CSS system colours
  - hurrah4b4con 4y ago
    [flagged]
    - enlyth 4y ago
      Dude... you need therapy
    - qup 4y ago
      I think you should email it to your congressman.
ahoy 4y ago
CSS is so cool, I've been writing it for a decade and I still keep leaning new, interesting things. Ty for sharing this!
- dotancohen 4y ago
  CSS is so frustrating. I've been dabbling in it for a decade and I still keep finding new, interesting incompatibilities. When will default browser stylesheets finally look decent enough to not need CSS for simple text-based sites? Though to be fair, TFA is an example of a step exactly in this direction.
  - ahoy 4y ago
    I'm also pretty bad at things i only dabble in. My Spanish is terrible, but that's not because Spanish is an inherently flawed language. It's because I haven't put in the consistent work to get good at it.
    - dotancohen 4y ago
      Good point. However, other technologies such as C++ or bash I can not touch for a year or two, then just bang out a small script when I need. But your point is certainly correct.
      - ahoy 4y ago
        And to be fair to you, I do concede that the process of learning CSS is messier and requires a bit more rote memorization than learning a "real" programming language.
1xdevloper 4y ago
This color-scheme property came in handy when I was implementing a modal dialog containing an iframe and a semi-transparent backdrop.
schemescape 4y ago
I’ll look at the stylesheet later, but how are they avoiding links on iOS being dark blue on a dark background? iOS’s default “dark” stylesheet is, unfortunately, not usable, and I’ve wondered if there’s a workaround that doesn’t involve me hard-coding specific colors. Edit: relevant WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=209851 https://bugs.webkit.org/show_bug.cgi?id=209851
- schemescape 4y ago
  I peeked at the site's stylesheet, and (it's pretty convoluted, but...) it appears to just be setting links to a theme color. So it seems they don't have a solution to this problem either :)
  - noahtallen 4y ago
    The site has a way to change the theme (custom accent colors), so I think the site doesn’t actually use default blue link colors
    - schemescape 4y ago
      Yes, you’re right. They avoided my problem entirely. I probably should have said that instead.
graypegg 4y ago
The CSS spec is always interesting for how much very useful stuff there is in it that’s buried under a magic incantation. I mean that as in, there’s little in the syntax to hint at the fact that Canvas as a colour exists. Some colours are camelCase (currentColor), others are uncased (rebeccapurple) and I guess these system colours are TitleCase? (CanvasText) I guess you just need to know!
- runarberg 4y ago
  These are actually case insensitive but are documented in different cases for claimed readability. From mdn (https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#system_colors https://developer.mozilla.org/en-US/docs/Web/CSS/color_value...): > Note: Note that these keywords are case-insensitive, but are listed here with mixed case for readability.
- deleted 4y ago
  [deleted]
- chrismorgan 4y ago
  Fun thing is that the system colours were originally written in lowercase <https://www.w3.org/TR/WD-CSS2-971104/ui.html#h-18.2 https://www.w3.org/TR/WD-CSS2-971104/ui.html#h-18.2>, then they dallied with kebab-case <https://www.w3.org/TR/1998/PR-CSS2-19980324/ui.html#system-colors https://www.w3.org/TR/1998/PR-CSS2-19980324/ui.html#system-c...>, but they finally settled on TitleCase <https://www.w3.org/TR/1998/REC-CSS2-19980512/ui.html#system-colors https://www.w3.org/TR/1998/REC-CSS2-19980512/ui.html#system-...>. As for currentColor, it follows SVG’s naming convention instead of CSS’s, because it was invented in SVG <https://www.w3.org/TR/SVG10/painting.html#SpecifyingPaint https://www.w3.org/TR/SVG10/painting.html#SpecifyingPaint> and only adopted into CSS proper because people thought, “hey, that’s a useful feature, and we like aligning HTML-CSS and SVG-CSS where possible”. (Not sure if it was case-sensitive or not; element and attribute names are, so <svg> gets a viewBox attribute, and viewbox won’t work, which I’ve seen inline-SVG-unaware HTML minifiers mangle to.) It has actually comparatively recently been partially renamed to currentcolor. https://www.w3.org/TR/css-color-4/ https://www.w3.org/TR/css-color-4/ mostly refers to it as currentcolor, but still has currentColor in a few places. Not sure if these are editing errors or not. My favourite is: “The serialized form of ‘currentColor’ is the string "currentcolor".”
_9hey 4y ago
I’m mid 30s and have been writing front end code since the late 90s and it never ceases to amaze me how straightforward and easy it has become. When XMLHttpRequest came out it felt like a HUGE hack to load stuff that wasn’t xml. In fact the only way to have a half decent website was to use an arsenal of hacks because browsers sucked
xp84 4y ago
Really a big fan of the underlying theme (no pun intended) here which is that your website or webapp should care significantly more about visually fitting in with the user's system, settings, and preferences than it should about expressing your corporate branding and looking the same on every device in the world. Users don't care about your "brand colors" and every "unique" UI element only serves to make their task of learning your site more annoying. In my career I have rarely run across anyone trusted to make visual design calls who is humble enough to agree with the above. Two different shades of black depending on which browser the user chooses? "Quick, file a bug!"
- joemi 4y ago
  > your website or webapp should care significantly more about visually fitting in with the user's system, settings, and preferences than it should about expressing your corporate branding and looking the same on every device in the world. I think it greatly depends on the website. For instance, I wouldn't expect a store's website to try to fit in with the user's system. Why should it? In that case, looking unique and standing out is a benefit. But if it's more of an app-type website, like a web mail client or some other utility that the user is likely to leave open for a while while working on stuff, then I think that's the type of site that should consider trying to fit in with the user's system. (Though I've never personally been of the opinion that I'd stop using an webapp just because it doesn't have darkmode or whatever.)
  - xp84 4y ago
    > In that case, looking unique and standing out is a benefit. In case of a store, having say, a share button that matches the Android standard for it, rather than the Apple version, makes more sense to Android users. It makes your site easier to learn which is a benefit. I am not saying all pages should be 100% "CanvasText" on "Canvas," and use the browser default font. There's so much room for customization that can be done. Splashes of color. One or two judiciously-chosen fonts that aren't jarring. However, the fact that we have at least 100,000 separate implementations of a 'dropdown/popup menu,' is not worth the downsides. Each of these custom controls has its unique bugs and accessibility flaws and they usually are inferior in many ways to the real UI elements that have been tuned for literal decades to work in all scenarios for all types of users.

Looks like support for "system colors" is up to 96% in 2023: https://caniuse.com/mdn-css_types_color_system-color https://caniuse.com/mdn-css_types_color_system-color

chrisfinazzo 4y ago
+10000 for the "lazy" Dark mode - it's excellent. Now if only I could find a use for #rebeccapurple again... a:hover, maybe??
- eimrine 4y ago
  Are you sure that this color is supported in every browser your website is going to be visited? Why not write "#639" instead?
  - chownie 4y ago
    If the browser doesn't support rebeccapurple then there's a whole bunch of other features that also won't work.
  - chrisfinazzo 4y ago
    You could use the shorthand, but it's really not necessary at this point. The spec is (unsurprisingly) quite [specific][1] that this color value is exactly "#663399". All browsers which implement CSS Colors have had support for years now and the Color Module itself is now a CR as of a year and a half ago. Incompatibility isn't exactly a rounding error yet, but we're close. [1]: https://lists.w3.org/Archives/Public/www-style/2014Jun/0312.html https://lists.w3.org/Archives/Public/www-style/2014Jun/0312....
- hanniabu 4y ago
  My lazy dark mode solution: html.dark-mode { filter: grayscale(100%) invert(100%); }
  - rawling 4y ago
    I had some fun inverting and then rotating the hue back around.
  - cubefox 4y ago
    This would also create negatives of pictures, right?
    - hanniabu 4y ago
      Correct. It's great for mostly text content or as a nice quick and dirty fix until you get around to creating a proper dark theme. Alternatively you can target elements individually, omitting images.
      - cubefox 4y ago
        Perhaps there is some fancy selector which excludes images?
        extra88 4y ago
        If you use just invert(100%), no grayscale, on the body, you can add img { filter: invert(100%) } to reverse images back to their original color. However, if an image has any transparency or translucency, it may be harder to see with what the background color has become.
  - tomxor 4y ago
    I've used something to this effect before, and you can use child selectors on e.g images to effectively exclude elements. Note that the cost of this lazy method is very poor performance (css filter over the entire document), and lack of control over dark colours (inverted colours don't necessarily work best, shifting hue can help but you probably don't want the same as uninverted colours because they tend to be too dark and lack sufficient contrast).
jrmg 4y ago
That site seems to suggest it’s supported on Firefox as far back as Firefox 2 in 2006, which doesn’t really jibe with the article.
- hrunt 4y ago
  The article points out that while system colors are supported in Firefox (as of the time of the writing of the article), the "color-scheme: light dark" method he was using was not supported, and it looks like that was not supported until Firefox 96 (January 2022).[0] [0] https://caniuse.com/mdn-css_properties_color-scheme https://caniuse.com/mdn-css_properties_color-scheme
  - Dalewyn 4y ago
    >until Firefox 96 (January 2022). Off topic, but the fact you felt a need to datestamp it indicates the Chrome Version Number System is bloody worthless.
chrismorgan 4y ago
This is misleading, and it would be nice if someone would correct it (after figuring out all the whats and whens). Its support table is for the CSS2 system colours, as defined back in 1997. <https://www.w3.org/TR/WD-CSS2-971104/ui.html#h-18.2 https://www.w3.org/TR/WD-CSS2-971104/ui.html#h-18.2> (Aside: “96.61%” is… well, for the type of browser they’re talking about—ones that support such things as CSS and colour—it should be exactly 100%, if not higher. Decide for yourself the sanity of this usage figure.) CSS Color Module Level 3 <https://www.w3.org/TR/css-color-3/#css2-system https://www.w3.org/TR/css-color-3/#css2-system> then deprecated them, for no good reason¹.² CSS Color Module Level 4 <https://www.w3.org/TR/css-color-4/#css-system-colors https://www.w3.org/TR/css-color-4/#css-system-colors> revived the concept of system colours, largely fixing the bad aspects and making it all clearly good. Some of the colours are still deprecated, with some at-risk³ dumbing-down. But there are also some new colours: Canvas and CanvasText. So the problem is that that MDN compatibility data is talking about CSS2 system colours, not CSS Color Module Level 4, which has much lower support (and may not all have been implemented at the same time: most were probably added around 2019, but some in 2021 and AccentColor and AccentColorText in 2022). Here are the actual colours, to help anyone who wants to update data (have fun identifying when they were added!): • New in CSS Color Module Level 4: AccentColor, AccentColorText, ActiveText, ButtonBorder, Canvas, CanvasText, Field, FieldText, LinkText, Mark, MarkText, SelectedItem, SelectedItemText, VisitedText. • Retained from CSS2: ButtonFace, ButtonText, GrayText, Highlight, HighlightText. • Deprecated from CSS2: ActiveBorder, ActiveCaption, AppWorkspace, Background, ButtonHighlight, ButtonShadow, CaptionText, InactiveBorder, InactiveCaption, InactiveCaptionText, InfoBackground, InfoText, Menu, MenuText, Scrollbar, ThreeDDarkShadow, ThreeDFace, ThreeDHighlight, ThreeDLightShadow, ThreeDShadow, Window, WindowFrame, WindowText. —⁂— ¹ Look, some of the system colours were clearly bad, modelling OS styles that were almost completely gone by this time. I suspect that some people didn’t like some of these too-specific values, and they threw the baby out with the bathwater. ² Earlier revisions mentioned the deprecation as being in favour of the ‘appearance’ property, but this was pretty stupid⁴ even when it was prospective, as first written, long before the ‘appearance’ property bit the dust for that time. ³ See <https://www.w3.org/TR/css-color-4/#deprecated-system-colors https://www.w3.org/TR/css-color-4/#deprecated-system-colors>: it defines fallback mappings that reduce the variations, but Firefox and Safari haven’t implemented the dumbing-down, still having the more-nuanced stuff they had from decades go. Hence “Results on these 'same as' equivalence tests are not great, which is why the feature is at-risk”. ⁴ No, seriously, just totally clueless and I have no idea what whoever wrote that was thinking, because it was always a completely different thing with only minimal potential overlap in uses.
mixmastamyk 4y ago
And the other almost 4% is "unknown" not specifically unsupported. Those browsers are unsupported ones from ancient Android releases.

hurrah4b4con 4y ago

[flagged]

acallaghan 4y ago
Alright but not sure what any of that has to do with CSS system colours
- hurrah4b4con 4y ago
  [flagged]
  - enlyth 4y ago
    Dude... you need therapy
  - qup 4y ago
    I think you should email it to your congressman.

ahoy 4y ago

CSS is so cool, I've been writing it for a decade and I still keep leaning new, interesting things. Ty for sharing this!

dotancohen 4y ago
CSS is so frustrating. I've been dabbling in it for a decade and I still keep finding new, interesting incompatibilities. When will default browser stylesheets finally look decent enough to not need CSS for simple text-based sites? Though to be fair, TFA is an example of a step exactly in this direction.
- ahoy 4y ago
  I'm also pretty bad at things i only dabble in. My Spanish is terrible, but that's not because Spanish is an inherently flawed language. It's because I haven't put in the consistent work to get good at it.
  - dotancohen 4y ago
    Good point. However, other technologies such as C++ or bash I can not touch for a year or two, then just bang out a small script when I need. But your point is certainly correct.
    - ahoy 4y ago
      And to be fair to you, I do concede that the process of learning CSS is messier and requires a bit more rote memorization than learning a "real" programming language.

1xdevloper 4y ago

This color-scheme property came in handy when I was implementing a modal dialog containing an iframe and a semi-transparent backdrop.

schemescape 4y ago

I’ll look at the stylesheet later, but how are they avoiding links on iOS being dark blue on a dark background? iOS’s default “dark” stylesheet is, unfortunately, not usable, and I’ve wondered if there’s a workaround that doesn’t involve me hard-coding specific colors. Edit: relevant WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=209851 https://bugs.webkit.org/show_bug.cgi?id=209851

schemescape 4y ago
I peeked at the site's stylesheet, and (it's pretty convoluted, but...) it appears to just be setting links to a theme color. So it seems they don't have a solution to this problem either :)
- noahtallen 4y ago
  The site has a way to change the theme (custom accent colors), so I think the site doesn’t actually use default blue link colors
  - schemescape 4y ago
    Yes, you’re right. They avoided my problem entirely. I probably should have said that instead.

graypegg 4y ago

The CSS spec is always interesting for how much very useful stuff there is in it that’s buried under a magic incantation. I mean that as in, there’s little in the syntax to hint at the fact that Canvas as a colour exists. Some colours are camelCase (currentColor), others are uncased (rebeccapurple) and I guess these system colours are TitleCase? (CanvasText) I guess you just need to know!

runarberg 4y ago
These are actually case insensitive but are documented in different cases for claimed readability. From mdn (https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#system_colors https://developer.mozilla.org/en-US/docs/Web/CSS/color_value...): > Note: Note that these keywords are case-insensitive, but are listed here with mixed case for readability.
deleted 4y ago
[deleted]
chrismorgan 4y ago
Fun thing is that the system colours were originally written in lowercase <https://www.w3.org/TR/WD-CSS2-971104/ui.html#h-18.2 https://www.w3.org/TR/WD-CSS2-971104/ui.html#h-18.2>, then they dallied with kebab-case <https://www.w3.org/TR/1998/PR-CSS2-19980324/ui.html#system-colors https://www.w3.org/TR/1998/PR-CSS2-19980324/ui.html#system-c...>, but they finally settled on TitleCase <https://www.w3.org/TR/1998/REC-CSS2-19980512/ui.html#system-colors https://www.w3.org/TR/1998/REC-CSS2-19980512/ui.html#system-...>. As for currentColor, it follows SVG’s naming convention instead of CSS’s, because it was invented in SVG <https://www.w3.org/TR/SVG10/painting.html#SpecifyingPaint https://www.w3.org/TR/SVG10/painting.html#SpecifyingPaint> and only adopted into CSS proper because people thought, “hey, that’s a useful feature, and we like aligning HTML-CSS and SVG-CSS where possible”. (Not sure if it was case-sensitive or not; element and attribute names are, so <svg> gets a viewBox attribute, and viewbox won’t work, which I’ve seen inline-SVG-unaware HTML minifiers mangle to.) It has actually comparatively recently been partially renamed to currentcolor. https://www.w3.org/TR/css-color-4/ https://www.w3.org/TR/css-color-4/ mostly refers to it as currentcolor, but still has currentColor in a few places. Not sure if these are editing errors or not. My favourite is: “The serialized form of ‘currentColor’ is the string "currentcolor".”

_9hey 4y ago

I’m mid 30s and have been writing front end code since the late 90s and it never ceases to amaze me how straightforward and easy it has become. When XMLHttpRequest came out it felt like a HUGE hack to load stuff that wasn’t xml. In fact the only way to have a half decent website was to use an arsenal of hacks because browsers sucked

xp84 4y ago

Really a big fan of the underlying theme (no pun intended) here which is that your website or webapp should care significantly more about visually fitting in with the user's system, settings, and preferences than it should about expressing your corporate branding and looking the same on every device in the world. Users don't care about your "brand colors" and every "unique" UI element only serves to make their task of learning your site more annoying. In my career I have rarely run across anyone trusted to make visual design calls who is humble enough to agree with the above. Two different shades of black depending on which browser the user chooses? "Quick, file a bug!"

joemi 4y ago
> your website or webapp should care significantly more about visually fitting in with the user's system, settings, and preferences than it should about expressing your corporate branding and looking the same on every device in the world. I think it greatly depends on the website. For instance, I wouldn't expect a store's website to try to fit in with the user's system. Why should it? In that case, looking unique and standing out is a benefit. But if it's more of an app-type website, like a web mail client or some other utility that the user is likely to leave open for a while while working on stuff, then I think that's the type of site that should consider trying to fit in with the user's system. (Though I've never personally been of the opinion that I'd stop using an webapp just because it doesn't have darkmode or whatever.)
- xp84 4y ago
  > In that case, looking unique and standing out is a benefit. In case of a store, having say, a share button that matches the Android standard for it, rather than the Apple version, makes more sense to Android users. It makes your site easier to learn which is a benefit. I am not saying all pages should be 100% "CanvasText" on "Canvas," and use the browser default font. There's so much room for customization that can be done. Splashes of color. One or two judiciously-chosen fonts that aren't jarring. However, the fact that we have at least 100,000 separate implementations of a 'dropdown/popup menu,' is not worth the downsides. Each of these custom controls has its unique bugs and accessibility flaws and they usually are inferior in many ways to the real UI elements that have been tuned for literal decades to work in all scenarios for all types of users.