Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

State of CSS

web.dev

Post reply on HN
Print view View original

61–70 of 234 posts

Re: State of CSS

#61

Post by irrational »

lbotos wrote: post #3

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://dowebsitesneedto…

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.

Re: State of CSS

#62

Post by gherkinnn »

martin_a wrote: post #20

I find most of this useless/overcomplicated. > Cascade layers Feels like we only need this because cascading works less and less well once you start to include multiple frameworks or pieces thereof. At some point people find themselves in a jungle of !important. If you keep the cascade small and clean, you'll most likely not need that. > Container queries Probably the designs I have to implement are not complicated e…

10 years ago people said the same about the CSS3 changes.

I find most of this useless/overcomplicated. Who needs rounded corners? I like my png slicing. And what are box shadows anyway? There's nothing flexbox can do that I can't achieve with tables. Transitions are bad, transparency is for Apple fanbois, animations the devil's farts, and don't get me started on media queries. Phones should remain Nokia bricks.

This isn't even a straw man. Further down we're still having the tables vs CSS debate. I'm so happy we got all of the above and more and can't wait to see what's next.

Re: State of CSS

#63

Post by jhgkjhlkhjkljk »

dmitriid wrote: post #4

Make no mistake: dialog element is there only because browsers (and Chrome, first and formost) want to remove alert/prompt. dialog was so problematic that the same people that are now promoting it were in favor of removing it entirely. Literally none of the issues were solved, but now it's a great new element that we all should use.

No post body was provided.

Re: State of CSS

#64

Post by commandlinefan »

gherkinnn wrote: post #62
martin_a wrote: post #20

I find most of this useless/overcomplicated. > Cascade layers Feels like we only need this because cascading works less and less well once you start to include multiple frameworks or pieces thereof. At some point people find themselves in a jungle of !important. If you keep the cascade small and clean, you'll most likely not need that. > Container queries Probably the designs I have to implement are not complicated e…

10 years ago people said the same about the CSS3 changes. I find most of this useless/overcomplicated. Who needs rounded corners? I like my png slicing. And what are box shadows anyway? There's nothing flexbox can do that I can't achieve with tables. Transitions are bad, transparency is for Apple fanbois, animations the devil's farts, and don't get me started on media queries. Phones should remain Nokia bricks. This…

> 10 years ago people said the same about the CSS3 changes

In OP's defense, I still say those things about the CSS3 changes.

Re: State of CSS

#65

Post by arrow7000 »

gherkinnn wrote: post #62
martin_a wrote: post #20

I find most of this useless/overcomplicated. > Cascade layers Feels like we only need this because cascading works less and less well once you start to include multiple frameworks or pieces thereof. At some point people find themselves in a jungle of !important. If you keep the cascade small and clean, you'll most likely not need that. > Container queries Probably the designs I have to implement are not complicated e…

10 years ago people said the same about the CSS3 changes. I find most of this useless/overcomplicated. Who needs rounded corners? I like my png slicing. And what are box shadows anyway? There's nothing flexbox can do that I can't achieve with tables. Transitions are bad, transparency is for Apple fanbois, animations the devil's farts, and don't get me started on media queries. Phones should remain Nokia bricks. This…

Exactly. Thank you for saying this. The curmudgeonliness on HN is ridiculous.

Re: State of CSS

#66

Post by psygn89 »

:has() basically removes the need for us to use JS to attach classes to parent elements as we can essentially look ahead now, e.g. ".some-component:has(.input-select-all:checked) { background: blue }" whereas we would have to use JS to query the input, then query the parent and attach some css class as a styling hook.

Container queries will allow us to fine-tune the not-so-predictable gaps between our predictable breakpoints. Breakpoints will probably still be used for larger-picture layout, but container queries will help with the smaller parts especially in UI that have many moving dynamic parts.

The rest are just icing and honestly I wouldn't be surprised if it takes a while for many of them to become mainstream.

Re: State of CSS

#67

Post by lbotos »

irrational wrote: post #61
lbotos wrote: post #3

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://dowebsitesneedto…

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?

Re: State of CSS

#68

Post by themacguffinman »

lbotos wrote: post #50
Vinnl wrote: post #47

Earlier quoted context omitted.

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…

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.

Re: State of CSS

#69

Post by clairity »

lbotos wrote: post #50
Vinnl wrote: post #47

Earlier quoted context omitted.

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 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).

Re: State of CSS

#70

Post by arrow7000 »

yakshaving_jgt wrote: post #54

As CSS gets bigger and more needlessly complex, I wonder if people start writing compile-to-CSS languages that aren't just supersets of the status quo. I could imagine (and I think I am possibly observing) CSS going a similar direction to JavaScript; we might soon see the CoffeeScript of CSS, and then eventually something more sophisticated and well-designed like the Elm of CSS. CSS — like JavaScript — might become t…

Is it really "needlessly" complex if this is enabling styling that wasn't possible before?

Re your second point that CSS might become a compilation target for styling... have you never heard of Sass, Less, Tailwind, or any of a million UI frameworks that provide alternative ways to write CSS, or even avoid writing it directly altogether? This isn't exactly new.

Post reply on HN