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

WebKit Supports Nested CSS

webkit.org

Post reply on HN
Print view View original

101–110 of 183 posts

Re: WebKit Supports Nested CSS

#101

Post by dgb23 »

SamEdosa wrote: post #87

This is great! The only reason I use SCSS is for the nesting. It should have been implemented 10 years ago, but better late then never.

It's great that parts of SCSS are getting superseded by CSS.

Nesting is great to avoid selector repetition.

Custom properties (CSS variables) and CSS functions give us tools to avoid magic numbers and to encode layout relationships.

New sets of selectors and container queries let us decouple and re-use declarations more.

CSS Houdini gives us further power in extending CSS functionality.

Of course there are things that SCSS provides which are unlikely in the scope of future CSS proposals such as datastructures (maps) and loops to generate classes and mixins. But I can already imagine a world were those aren't necessary anymore for many cases.

Re: WebKit Supports Nested CSS

#102

Post by the_other »

bryanrasmussen wrote: post #100
ocimbote wrote: post #64

Earlier quoted context omitted.

If syntactic sugar was really just sugar, JS would have sticked to callback functions, and we’d still be inventing abstractions to make our lives easier. Syntactic sugar, sometimes, is the promise of sunnier mornings and that matters.

unpopular opinion I'm sure from reading everyone here, but to me nesting css is syntactic poison - or maybe syntactic sucrose or something that gives you cancer you use too much of it? Anyway programmers given nesting just do it all the time which ends up leading to stuff like article.news section.preamble h1 and probably a few other selectors after that all nested giving you a wonderful high priority for your style…

I’ve seen this plenty of times in CSS codebases. Nesting is a write-time optimisation but a read-time hinderance.

If users stick to nesting for lightweight scoping, things will go well. But they wont: they’ll use it to DRY every possible line and their inheritors will suffer dehydration.

Re: WebKit Supports Nested CSS

#103

Post by bryanrasmussen »

the_other wrote: post #102
bryanrasmussen wrote: post #100

Earlier quoted context omitted.

unpopular opinion I'm sure from reading everyone here, but to me nesting css is syntactic poison - or maybe syntactic sucrose or something that gives you cancer you use too much of it? Anyway programmers given nesting just do it all the time which ends up leading to stuff like article.news section.preamble h1 and probably a few other selectors after that all nested giving you a wonderful high priority for your style…

I’ve seen this plenty of times in CSS codebases. Nesting is a write-time optimisation but a read-time hinderance. If users stick to nesting for lightweight scoping, things will go well. But they wont: they’ll use it to DRY every possible line and their inheritors will suffer dehydration.

not just read-time, but yes it is that as well, I find a class I search for this class, now I need to understand all scope in html tree and scope of the css to understand am I looking at the right one (sure you can run into situations with that as well, but in my experience nesting makes it more difficult)

but it is also a source of bugs, because complicated selectors mess with css priority and the cascade then someone writes something that has side effects and blame CSS instead of their ridiculously long nesting.

Re: WebKit Supports Nested CSS

#104

Post by dgb23 »

bryanrasmussen wrote: post #100
ocimbote wrote: post #64

Earlier quoted context omitted.

If syntactic sugar was really just sugar, JS would have sticked to callback functions, and we’d still be inventing abstractions to make our lives easier. Syntactic sugar, sometimes, is the promise of sunnier mornings and that matters.

unpopular opinion I'm sure from reading everyone here, but to me nesting css is syntactic poison - or maybe syntactic sucrose or something that gives you cancer you use too much of it? Anyway programmers given nesting just do it all the time which ends up leading to stuff like article.news section.preamble h1 and probably a few other selectors after that all nested giving you a wonderful high priority for your style…

Well yes, nesting is inherently a concretion that can lead to overly specific selectors. One of our/my style guide rules is to avoid nesting (in SCSS) when it's unnecessary. When nesting is used it should read "this declaration only makes sense in this nested context".

But not having nesting at all is similarly problematic as having too much nesting, because it can lead to repetition, proliferation of classes and brittleness.

Re: WebKit Supports Nested CSS

#106

Post by amjnsx »

SamEdosa wrote: post #87

This is great! The only reason I use SCSS is for the nesting. It should have been implemented 10 years ago, but better late then never.

For me this is where something like PostCSS shines. You simply write future css and remove the plugin when it’s supported natively.

This wins in my opinion because there shouldn’t be any conversion necessary from something like Sass to CSS

Re: WebKit Supports Nested CSS

#107

Post by whstl »

lofaszvanitt wrote: post #105

"Everyone wishes CSS nesting could use the same kind of simple syntax that Sass does. That’s impossible" Oh man... let the asteroid come.

This is a good thing.

I'm currently writing a toy "javascript" bundler. I implemented a CSS parser in the past (mostly for linting) and it took me a few hours. Trying to do the same with SCSS made me give up halfway. The test suite was >6000 tests or so and I got up to about 3000 or something, but it gets harder the further up you go. There's lots of other people in Github that are smarter than me and had the same experience, leaving their parser halfway finished. There's a lot of smart stuff in SCSS, and that is perfectly fine for a compile-time tool, but it's not something that's fast enough for a browser, or simple enough that can be added quickly to their current parsers.

Re: WebKit Supports Nested CSS

#108

Post by whstl »

bryanrasmussen wrote: post #100
ocimbote wrote: post #64

Earlier quoted context omitted.

If syntactic sugar was really just sugar, JS would have sticked to callback functions, and we’d still be inventing abstractions to make our lives easier. Syntactic sugar, sometimes, is the promise of sunnier mornings and that matters.

unpopular opinion I'm sure from reading everyone here, but to me nesting css is syntactic poison - or maybe syntactic sucrose or something that gives you cancer you use too much of it? Anyway programmers given nesting just do it all the time which ends up leading to stuff like article.news section.preamble h1 and probably a few other selectors after that all nested giving you a wonderful high priority for your style…

I agree with you.

I worked in several codebase that used SCSS and due to those little hacks popping up in review, every time we ended up putting a "rule" in place to stick to two levels of nesting at most, or 3 if you're using the third nesting-level for pseudo-selectors (:hover :before etc). And this rule very rarely had to be broken, as it was extremely easy to avoid being too clever with nesting. (Of course, if there was a real good technical reason, we'd "break" it too).

Re: WebKit Supports Nested CSS

#109

Post by hollowturtle »

This won’t kill Sass/scss. Compilers will still be useful for many reasons, I see those compilers targeting new standards instead. Also, bummer that nested rules made it but was removed. The only viable option for me today to keep a maintainable css code base is to use a css in js solution and a compiler. In fact I don’t see why all this excitement for native features, if all you need could be just a capable compiler(bundling, minification, optimization, dead code elimination etc.)

Re: WebKit Supports Nested CSS

#110

Post by jhughes982 »

cunningfatalist wrote: post #74

I am not a big fan of nesting. I have yet to see a codebase where nesting makes CSS more readable. Even with BEM, I find it easier to reason about (and debug) the vanilla style. However, I must admit that `&:hover{}` does have a certain appeal. Also, I am very happy that nesting can be done without tooling in the future. It's a feature that many people love.

I agree, for some reason my brain sees the non-nested versions of CSS as more readable. Although we seem to be in the minority here. Very open to trying out nesting and perhaps my brain will 'flip' to eventually prefer it.
Post reply on HN