Hacker News Reader

Hacker News

Comment by lbotos | Hacker News Reader

Full thread

lbotos

Does anyone else feel like CSS has jumped the shark a bit?

https://web.dev/state-of-css-2022/#accent-color

Sure it's a "nice to have" but it bloats the spec? Look at the current actual implementation:

https://web.dev/accent-color/#guaranteeing-contrast

chrome and firefox already tint differently...

How is this better than a good ol CSS variable and leaving it up to the designer to manage?

Sure http://dowebsitesneedtolookexactlythesameineverybrowser.com/ but when the exec is like "why is our brand color slightly different on ff vs. chrome... we are back to square one.

View on HN

I guess all these additions are incentivized by google etc loving the fact that it makes the moat to make competing browsers wider and wider. Imagine trying to make a new browser from scratch in 2022 and supporting the 20+ years of bloat like this (not to mention future plans).

Did you even bother to look which browser implemented the features first? Will you update your priors based on what you find?

I'm talking about the growth of features in general. Calm down no need to be so aggressive.

No need to be so conspiratorial either. Generally features make it in because they improve developers' experience.

They are mostly one-off features that don't create a coherent whole. See what Figma has to say about this: https://www.figma.com/blog/building-a-professional-design-to...

For this? No. Years ago we were working on a project and the default color of the form elements was a real sticking point. For some of them we ended up rolling our own, but others we just suffered with the default. Accent-color would have solved a problem we spent months working on and agonizing over.

See my reply below: https://news.ycombinator.com/item?id=33289468

If you were able to style the element with "classic" CSS primitives like border/background/color would that not have also solved the problem without introducing new syntax with new quirks?

I've done this before. The problem is a lot of elements will change to a different (standard?) appearance when you add styles like that, so you'd need to recreate the original look if you wanted to just change the color. Also, each browser has different psuedoelements so you have to support firefox and webkit separately, which is made worse by the fact that webkit doesn't support targeting multiple elements with your psuedoelement selector, ex. you can't do this:

  input[type="range"]::-moz-range-thumb,
  input[type="range"]::-webkit-slider-thumb {
    background-color: red;
  }

It'll work in Firefox, but Chrome (and probably Safari) will ignore it. Instead you need to do this:

  input[type="range"]::-moz-range-thumb {
    background-color: red;
  }
  input[type="range"]::-webkit-slider-thumb {
    background-color: red;
  }

For what it’s worth, having forms work the same across browsers is something Apple, Google and Mozilla are working on for Interop 2022: https://wpt.fyi/interop-2022

Looks like they're mostly working on making the appearance property work the same across browsers, they aren't actually standardizing the shadow dom used to render the elements.

Good joke, an exec testing in different browsers to ensure the color tint is the right color.

I feel like the more typical reality is an exec looking at the site on some random browser or device, that then has to be in the support matrix, e.g. an enterprise business web app that supports the most recent 2 versions of modern desktop browsers...and the Silk browser for Kindle Fire because that's what's on the CEO's coffee table.

This is why I quit working on Frontend honestly, I was constantly juggling such bs requirements.

their 6 year old Lenovo with ie10

As a person who had to make some custom newsletter compatible with IE8 few years ago, for the 1% who still used it but among of them some were the most important investors, I feel this.

I mean, I get what you're saying, but for a company with critical branding needs, they will absolutely be concerned by this. In many instances they might even notice themselves. Sure, your average software company CEO won't care, but if you're in the food and bev business, or a design firm, or a game developer, the execs are keenly aware that micromanaging their public image is essential. That's why they spend millions of dollars for logo redesigns, or in a more extreme case, spend a huge chunk of change to make their own sliiiightly different version of Helvetica like Target did.

I was not possible to use a CSS variable to change the highlight colour of a checkbox, as far as I'm aware. You can use a CSS variable to set the accent-color, though.

(The workaround was creating a fake element that looked like a checkbox that overlapped the actual checkbox.)

Right, my point is, we've now introduced this new attribute for "browser elements" instead of saying now checkboxes support background-color, color, etc. And let the designer do the work.

Lean on the primitives we already have, enable flexibility, and if someone wants to make a SaSS wrapper or CSS function to do it, enable that vs. more random places for browsers to diverge on "standards".

It plays out like this:

"Oh, I wanna change the UI element style, thats a new feature! Accent-color! Nice. Oh wait, browsers are doing different things. Dang. Am I okay with that? vs. "I wanna change a UI element style, Oh, browsers now support classic CSS styling attributes on these elements! Nice! Designers sets colors, all browsers just read the designer's palette.

Changing the behavior of existing attributes isn't backwards compatible. Websites that currently use background-color & color assuming that it won't affect the accent color will suddenly look different when new browser versions make it affect the accent color.

i believe the problem with form elements like checkboxes is that they are 'replaced elements', which the browser defers to the underlying operating system, and that's why it requires a "hack" like accent-color rather than direct styling. this is also why you can't use ::before and ::after on form elements (to do things like add a 'required' indicator using css only).

IIRC they used to, but not anymore. They're implemented with a special Shadow DOM that's not accessible by the page but you can style some elements if the browser exposes them as psuedoelements.

are OG form elements actually reimplemented in shadow DOM, like they're doing with open UI (https://open-ui.org/) custom elements?

i've seen safari and chrome (but not firefox) expose some form input components as shadow DOM (e.g., slots), but wasn't sure if it was actually reimplemented.

Yep, there are settings to show them in the devtools for both Chrome and Firefox. You can't access them with JS though, you can only see them in the devtools.

> The workaround was creating a fake element that looked like a checkbox that overlapped the actual checkbox

There is also a newer workaround by styling the input element it self by using appearance: none. You can do some clever stuff with the :checked selector, multiple backgrounds, clip-paths, masks, etc.

I write complex web apps and hit the limits of CSS every day. My apps are written in a way that allows easy changing of themes and `accent-color` particularly can greatly simplify my theme management system.

I'm super excited for some of these additions. Perhaps they are meant for designer-developers such as myself and not for the casual CSS developer who doesn't already reach for existing advanced features.

I don't know if a single addition is enough reason to claim that the entire language has jumped the shark - but I was also wondering how this is different than a variable.

> CSS has jumped the shark

"Disregard logic, acquire funds" - Ducreux

Reply on news.ycombinator.com