Live data from Hacker News

WebKit Supports Nested CSS

webkit.org

131–140 of 183 posts

Re: WebKit Supports Nested CSS

#131
post #41

Nested rules is just a syntax sugar. In Sciter, 10 years ago, I came up with style sets: @set Main { :root { ... } // root element that has this set applied .bar { ... } article { ... } :root > article { ... } } main { style-set: Main; } // main element with the set applied This solution solves two problems: 1. Modular/componentized style definition - same goal as in nesting styles, but without introduction of new sy…

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.

Well, that's the matter of live systems design.

When you want to add a feature you should ask first if that can be accomplished by existing mechanisms.

And the second, if to go with with the change that affect millions of users, can we solve not just one problem (that already has a solution like LeSS & Co.) but possibly other principal too?

So for #1. If we already have @media sections, why not to use the same notation?

   @media name { ...rules... }
and

   @set name { ...rules... } 
@set can use existing code in parsers. Not just in browsers but in tons of existing tools and editors that do syntax highlighting.

And #2. Style sets solve problem of global CSS namespace pollution.

Consider this rule:

   div [name="some"] { ... }
then, while calculating styles of DOM elements, absolutely all N DOM elements need to be checked against this rule. So it is a O(N) complex task. And proposed nested rules thing does not reduce the N, but may make this even worse - more rules will be used.

While in style set solution:

   @set ComponentA {
      div [name="some"] { ... }
   } 
that rule will be checked only against children of componentA - the rule is local/scoped to DOM subtree. Still O(n), but n <<< N.

Re: WebKit Supports Nested CSS

#132
post #106

Earlier quoted context omitted.

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

What's the hit/miss rate on that CSS changing syntax? I Vaguely recall something similar happening with decorator syntax/how it worked in JS/typescript. Or do you keep to CSS features that are locked down in terms of spec, just waiting on implementation to roll out?

It’s your call fortunately/unfortunately.

The safe option is obviously to install plugins for features that are close to passing as possible, where the api is stable at least - but there are plugins for very early stage proposals too.

Re: WebKit Supports Nested CSS

#133
post #3

> Back in December, we wrote an article detailing three different options for CSS Nesting. > Web developers responded to the poll with great clarity. Option 3 won in a landslide. Yup, pretty much. The only thing I really wish won however was making the beginning "&" always required for nesting. Instead you're able to omit it if there's any other symbol. Example from article: main { .bar { ... } #baz { ...} :has(p) {…

> Hard to see the use-cases for sass in 2024

Modules make writing CSS much less of a naming game. Anything you can do to reduce one of the 2 hardest problems in CS is worth it.

Re: WebKit Supports Nested CSS

#134

Earlier quoted context omitted.

> Hard to see the use-cases for sass in 2024 Possibly mixins, loops, and variables, which, unlike CSS variables, can be used in media queries.

>Possibly mixins, loops, and variables, which, unlike CSS variables, can be used in media queries. Please god no. CSS is intended to be completely declarative. Loops and conditional logic were the very worst ideas SASS ever had.

People want freedom (as seen by the down-votes comment above seems to have gathered) and I do remember the old times when I was very excited for the creativity SASS allowed me.

Then in-between then and now, I did a lot of consulting work, and now I'm strongly feeling that the more DRY you try to make CSS, the more you end up writing, and unmaintainable CSS at that. Random example:

https://github.com/primefaces/primeflex/blob/master/_sass/li...

SASS is too powerful for its own good.

TL;DR: I wholeheartedly agree with the above comment.

Re: WebKit Supports Nested CSS

#135
post #3

> Back in December, we wrote an article detailing three different options for CSS Nesting. > Web developers responded to the poll with great clarity. Option 3 won in a landslide. Yup, pretty much. The only thing I really wish won however was making the beginning "&" always required for nesting. Instead you're able to omit it if there's any other symbol. Example from article: main { .bar { ... } #baz { ...} :has(p) {…

> Web developers responded to the poll with great clarity. Option 3 won in a landslide.

Because there was no “none of the above” option, which developers asked for.

Re: WebKit Supports Nested CSS

#136

Maybe I am an outlier... but I really don't like nested style documents like those founds with SASS, LESS, PostCSS. When the number of nested selectors becomes too great it can become very difficult to reason about. I would never use this without some kind of lint rule enforcing a maximum depth of selector nesting. I agree with the other commenters ITT taking the position flat CSS looks cleaner than nested documents.

It’s Sass & Less, not SASS & LESS. Less is sometimes stylized with all caps (or all lower like {less}) and is an acronym for Leaner Style Sheets, but Sass was never was stylized with all caps nor is it an acronym.

Re: WebKit Supports Nested CSS

#137
post #101

Earlier quoted context omitted.

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 tha…

> SCSS are getting superseded by CSS. Reminds me of how Coffeescript died out because its best ideas got integrated into Javascript. What I want to know is: how the hell did this take so long? Nesting is such an obviously useful feature to have in CSS, and once I'd experienced it in SASS I never wanted to be without it. Why did it take 10+ years for this to be introduced to CSS, especially when other browser-based te…

For another take: I try to write a single module.css file per component in which I do zero nesting, avoiding any preprocessors (other than postcss modules, obviously). Nesting, IMHO, makes CSS a bit easier to write but much harder to read.

Re: WebKit Supports Nested CSS

#138
post #3

> Back in December, we wrote an article detailing three different options for CSS Nesting. > Web developers responded to the poll with great clarity. Option 3 won in a landslide. Yup, pretty much. The only thing I really wish won however was making the beginning "&" always required for nesting. Instead you're able to omit it if there's any other symbol. Example from article: main { .bar { ... } #baz { ...} :has(p) {…

> Hard to see the use-cases for sass in 2024 Possibly mixins, loops, and variables, which, unlike CSS variables, can be used in media queries.

yes, mixins. even just static sets of declarations would be a great start, e.g., wanting to apply the same set of base rules to both an entity and various classes without error-prone repetition (which you typically separate to have control over cascading and specificity).

css variables in media queries would be helpful too, but mixins to me is the next big step after :has() (oh so useful, come on firefox!) and this nested css syntax. unfortunately, it may be years for us to see it in browsers. there's no consensus yet on mixin syntax or where in the css lifecycle it would be implemented (there are potentially serious performance implications apparently).

Re: WebKit Supports Nested CSS

#139
post #45

I am supportive of this. Ofc, parent selector would still be nice, but I understand the problems solving that performantly. As a highlight, Nested CSS doesn't support nested selectors if they both begin with letters, so the "&" is used as divider. I highly recommend web-dev's check out the last section of the article*: https://webkit.org/blog/13813/try-css-nesting-today-in-safar... [*: even though, IMO, in this insta…

We have a parent selector. It's called :has(), and Firefox is the only holdout at this point.

You can enable it with a flag in Firefox though. If only I could enable subgrid with a Blink flag though ha.

Re: WebKit Supports Nested CSS

#140
post #3

> Back in December, we wrote an article detailing three different options for CSS Nesting. > Web developers responded to the poll with great clarity. Option 3 won in a landslide. Yup, pretty much. The only thing I really wish won however was making the beginning "&" always required for nesting. Instead you're able to omit it if there's any other symbol. Example from article: main { .bar { ... } #baz { ...} :has(p) {…

> Hard to see the use-cases for sass in 2024 Modules make writing CSS much less of a naming game. Anything you can do to reduce one of the 2 hardest problems in CS is worth it.

Or build a design system with good names and take advantage of the global nature of standard CSS.
Post reply on HN