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

71–80 of 234 posts

Re: State of CSS

#71

Post by willio58 »

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…

Container queries allow devs to step away from the classic small, medium, large breakpoints for screen sizes and consider the best look for a certain component at different widths. This is much better because a component on screen can be affected by many different parent element’s breakpoints, so it’s hard to define when a screen size should affect a component. With containers, it’s very clear.

Re: State of CSS

#72

Post by willio58 »

wbobeirne wrote: post #33
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 nothing new, you could already use pointer-events: none or tabindex or put a transparent div on top. This is just a better way to hint to the browser your intent, and for it to behave properly.

Does pointer events block focusing with a keyboard though?

Re: State of CSS

#73

Post by arrow7000 »

commandlinefan wrote: post #64
gherkinnn wrote: post #62

Earlier quoted context omitted.

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.

Good for you. The rest of us will be using these new features to make great websites with far less wasted time and effort than before.

Re: State of CSS

#74

Post by arrow7000 »

reaperducer wrote: post #49
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…

No. If you have to write styling in JS I can guarantee that it will be far more brittle, less performant, and way more susceptible to FOUCs, reflows, jank, and potentially deadlocks of conflicting resizing elements than the equivalent in CSS.

Re: State of CSS

#75

Post by willio58 »

dimmke wrote: post #46
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 d…

I’m building a CMS and container queries will make the components I build sooo much better.

Re: State of CSS

#76

Post by dheera »

Yet 15 years later, I still can't specify a width and aspect ratio for an div without some unintuitive nested div hell.

Re: State of CSS

#77

Post by yakshaving_jgt »

arrow7000 wrote: post #70
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.

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

Many newer features that have been added over the years don't actually enable anything new. Not that I'm arguing in favour of table-based layouts either.

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

I have written CSS in a serious capacity for several years. I am more than familiar with Sass, Less, etc., which is exactly why I wrote "languages that aren't just supersets of the status quo".

Re: State of CSS

#78

Post by jjcm »

Interesting to see a lot of negative responses here. I'm quite excited for a large amount of these items.

@container queries are going to help a ton in making components more reusable - components that react to their own size rather than the browser size have been needed for a long time, and currently the only way to really do it is with the javascript observer api, which comes with huge performance tradeoffs.

Color-mix() is another item I've been wanting for some time, not because I need to mix things like red + blue, but because we've needed a native way to add opacity to css variables for a long time now. Having opacity be independent means we can have a robust design system that doesn't expand exponentially, while still providing opacity levels when needed.

Masonry layouts will greatly simplify a very common use case, color level 4 and 5 will make the web more dynamic and beautiful, and loosely typed properties will help add fallbacks. Definitely excited for these changes.

Re: State of CSS

#79

Post by nailer »

Give me:

- mixins. Like SCSS and SASS has had for a decade now. 'apply' was supposed to add mixins but 'apply' was cancelled in favour of 'part', and 'part' doesn't work. https://stackoverflow.com/questions/74097950/how-do-i-create...

That's actually it. We already have aspect-box, adding gradients for borders would be nice but I can live without them.

Re: State of CSS

#80

Post by [deleted] »

johnfn wrote: post #59
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 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.

[deleted]
Post reply on HN