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

41–50 of 234 posts

Re: State of CSS

#41

Post by noduerme »

toastercat wrote: post #2

Great overview. I'm always excited by newer features to CSS that make older JS-only methods obsolete. I've also grown CSS-tooling fatigued after using SASS and PostCSS plugins for years. I've recently gone back to only using vanilla CSS on personal projects and while there are niceties I do miss (nesting) it's refreshing not having to deal with config files or waiting for stuff to compile.

I couldn't live without SCSS mixins, extensions and maps. The sheer tedium of doing it vanilla would drive me insane.

Re: State of CSS

#42

Post by ezfe »

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…

Inert is needed for

Re: State of CSS

#43

Post by kevincox »

fouronnes3 wrote: post #39

Is there any work on updating CSS browser defaults? Even if it must be opt-in to keep backwards compat, having the possibility of starting any css file with 'use-defaults: 2022;' or something like that would be great.

I would love an option to opt into something like "reader mode" but maybe not quite so restrictive. (I can use some custom CSS to highlight code and some JS for interactive examples.

Right now I need to worry about the user's contrast preferences, light/dark preferences. Decide if I want to force a decent font or end up with the user's default (which probably sucks). I need to decide the text size (because their default probably sucks) and decide how wide the reading area should be.

What a mess to try and just pick something that the user wants.

Re: State of CSS

#44

Post by djrockstar1 »

jacobsimon wrote: post #25
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…

Container queries is a big deal in my opinion! This has always been an obstacle for designing responsive components - they only respond to the size of the screen so designing them for use in different places in your app is difficult. But the implementation they’ve chosen with named containers is not my favorite. I’d prefer one that is simply based on the parent component or the closest component with a container attr…

Yeah container queries are what I'm most excited about looking at this list. I was pretty bummed out to see they're only supported on 63.75% of browsers, and notably missing on most mobile browsers, where they'd be most useful.

Re: State of CSS

#45

Post by devX3 »

waboremo wrote: post #8
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…

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

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.

Re: State of CSS

#46

Post by dimmke »

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…

I recently implemented layers on my site https://daniel.do/ and honestly found it really helpful in terms of explicitly organizing specificity.

It also gives you a much clearer idea of where in your styling stack something is coming from.

> Container queries

Have you ever built a piece of functionality that goes on pages you don't control? For instance, I built software that displayed a map on people's pages. but I don't know the width of the map itself. They could be displaying it on the full width of their page or in a container. Media queries don't work in this scenario. Making the map correctly responsive forced me to use JavaScript to get the element's width.

The other solution people have for this is iframes, which suck too.

Just because you don't have a need for something doesn't mean nobody does.

Re: State of CSS

#47

Post by Vinnl »

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…

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

Re: State of CSS

#48

Post by devX3 »

macNchz wrote: post #31
waboremo wrote: post #8

Earlier quoted context omitted.

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.

Re: State of CSS

#49

Post by reaperducer »

toastercat wrote: post #2

Great overview. I'm always excited by newer features to CSS that make older JS-only methods obsolete. I've also grown CSS-tooling fatigued after using SASS and PostCSS plugins for years. I've recently gone back to only using vanilla CSS on personal projects and while there are niceties I do miss (nesting) it's refreshing not having to deal with config files or waiting for stuff to compile.

I'm always excited by newer features to CSS that make older JS-only methods obsolete.

I wonder if it's just about how some people's brains are wired.

I grok CSS. I won't claim to know everything about it, but I'd say I'm 90% proficient and prefer it to JavaScript.

But I think this is because JavaScript somehow never fully made sense to me. I can read it and figure out what it's doing, but it was never intuitive to me the way CSS is.

I read comments on HN frequently from people who are good a JS, but can't deal with CSS.

I think it's just how some languages "click" with different people. Some are comfortable in Lisp, while others are AP/L, or Rust, or something else.

Perhaps it's good to have multiple ways to achieving the same thing, rather than obsessing about one perfect/standard/preferred/"best practice" way of doing things.

Re: State of CSS

#50

Post by lbotos »

Vinnl wrote: post #47
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…

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.

Post reply on HN