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

161–170 of 183 posts

Re: WebKit Supports Nested CSS

#161

Post by 65 »

cphoover wrote: post #32

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.

If you give a junior front end developer CSS nesting, you can get some very janky results.

Working with SCSS codebases and junior developers, I've seen SCSS nesting get so bad, the line order of the selector in the stylesheet would determine what styling gets used.

Nesting CSS is useful in some cases, but for the majority of use cases it can get unwieldy very quickly.

Re: WebKit Supports Nested CSS

#162

Post by WorldMaker »

kerkeslager wrote: post #152
chrismorgan wrote: post #128

Earlier quoted context omitted.

See https://github.com/w3c/csswg-drafts/issues/7961 , which details some of the problems, including genuine and currently irreconcilable ambiguities, and goes into attempting to make it work by adding convoluted and complex rules and arbitrary lookahead in a way that I really strongly hope gets nixed because it’s awful. (And they’re really only trying to do this because they resolved to make & optional in #7834, whic…

Sorry, all the irreconcilable ambiguities are conflicts with other, not-yet-accepted proposals, with one exception, a conflict with JS tools that use JSON to spit out CSS. I'd argue that there are other syntax options for those other not-yet-accepted proposals, and this is likely to be a more-used feature than any I saw. And forcing some poorly-designed JS tools to come up with a minor workaround just isn't something…

The parsing time issue is "in the standard now". Even if no rule today matches `property: value { something in brackets }`, that's still at least three tokens (`property`, ':', 'value') to read before bailing out at a bad "property" because values "shouldn't" have things in brackets. (You can build examples with complex CSS selectors where it becomes way more than 3 tokens, as well.)

CSS was designed to be "forgiving" of malformed input, so there's generally no "early" bailout the parser can make, even if it doesn't think it knows which property you are talking about and has a whitelist of specific properties it supports.

Re: WebKit Supports Nested CSS

#163

Post by c-smile »

Sesse__ wrote: post #154
c-smile wrote: post #131

Earlier quoted context omitted.

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

Contemporary CSS engines use bucketing, so a rule like div[name="some"] will only ever be considered for something that has (depending on your browser implementation) either a “name” attribute or is a . In other words, “Absolutely all N DOM elements need to be checked” is completely wrong. It's worst-case O(n), sure, but on a practical page nowhere near average-case O(n). As for @media queries, I can't say anything a…

> bucketing ...

"All of that is very different between the various engines, making the whole process even less predictable."

Source: https://benfrain.com/css-performance-revisited-selectors-blo...

In worst case complexity of styles resolution is O(nS*nD) where nS is a number of style rules and nD is a number of DOM elements. That's for current flat style table used by CSS. You can optimize bits and cases but it in general problem is like that.

> @media queries ... at least in Blink they're handled entirely different.

@media and @set are different mechanisms. :root in @set matches element that has this set applied. @set's are scoped set of rules. @media are not.

But I was talking about different thing - parsing, in particular in syntax highlighters and other tools.

----

Consider this DOM:

   
     ...
     ...
And CSS:

   @set aside-set {
     :root {...}
     ... nA more rules
   }

   @set main-set {
     :root {...}
     ... nM more rules
   }
content style resolution will always be constant and independent from , no matter how many nM rules you will have. While currently (with the flat table) adding rules for content will increase complexity of DOM resolution too.

As a bonus: rules in two sets are completely isolated. Adding rule in main-set will never break existing aside design.

Re: WebKit Supports Nested CSS

#164

Post by adam_arthur »

spankalee wrote: post #40
kijin wrote: post #17

:is(article) & That looks hacky at best. The excuse of parsing performance is responsible for so much weird syntax in web standards today. The standards are literally being dragged around by browser vendors' priorities. I wish they would do it the other way around for once: come up with the cleanest, easiest-for-humans syntax as possible, and tell browser vendors to fix their damn engines. Perhaps this will lead to t…

> tell browser vendors to fix their damn engines Parsing performance of the type they're talking about is an algorithmic fact, not an implementation problem. Your suggestion is like telling engineers to fix the laws of physics.

SASS parses along those exact nesting rules, so clearly it's possible for the browser to do it as well. Just a question of performance hit at runtime.

In the end having the runtime be fast is likely more important than perfect syntax (as we can still pre-compile via better syntax), but the actual numbers and real world use cases matter a lot.

Are these worst case performance scenarios actually realistic or common? I didn't see anybody speaking to that, but also haven't followed this issue in years. I have seen on a lot of the web standards discussions that many of the contributors will pose theoretical worst case situations as something that should meaningfully impact design of a feature, when those worst case scenarios are extremely rare and unrealistic in practice.

Re: WebKit Supports Nested CSS

#165

Post by Sesse__ »

c-smile wrote: post #163
Sesse__ wrote: post #154

Earlier quoted context omitted.

Contemporary CSS engines use bucketing, so a rule like div[name="some"] will only ever be considered for something that has (depending on your browser implementation) either a “name” attribute or is a . In other words, “Absolutely all N DOM elements need to be checked” is completely wrong. It's worst-case O(n), sure, but on a practical page nowhere near average-case O(n). As for @media queries, I can't say anything a…

> bucketing ... "All of that is very different between the various engines, making the whole process even less predictable." Source: https://benfrain.com/css-performance-revisited-selectors-blo... In worst case complexity of styles resolution is O(nS*nD) where nS is a number of style rules and nD is a number of DOM elements. That's for current flat style table used by CSS. You can optimize bits and cases but it in ge…

> In worst case complexity of styles resolution is O(nS*nD) where nS is a number of style rules and nD is a number of DOM elements. That's for current flat style table used by CSS. You can optimize bits and cases but it in general problem is like that.

Worst-case isn't really interesting for browsers, though. CSS doesn't have an adversarial performance model.

> @media and @set are different mechanisms. :root in @set matches element that has this set applied. @set's are scoped set of rules. @media are not.

Again, this roughly matches @scope (where :scope matches the element that has the given selector applied). But this is just a fantasy spec, right? There are no browsers that implement this, and just like with @scope or nesting or CSS at all, there's no guarantee in the spec what performance characteristics you would have?

FWIW, if you want something like this and get it through CSSWG, you'll most likely see it end up with worse performance than flat CSS, unless it becomes _really_ popular and browsers see the need to optimize certain sub-cases of it (the general case, with tons of different sets, will be nearly impossible to make really fast).

Re: WebKit Supports Nested CSS

#167

Post by jonny_eh »

__ryan__ wrote: post #160
adamwathan wrote: post #147

One thing worth noting is that & substitutes for `:is(...)` in spirit under the hood, which means there are some significant behavior differences between native CSS nesting and Sass. Here's one: .foo .bar { .baz & { color: red; } } In Sass, that would compile to: .baz .foo .bar { color: red; } With native nesting, it effectively compiles to: .baz :is(.foo .bar) { color: red; } The Sass version matches this DOM struct…

I’ll criticize it. I recognize this is a preview and I desperately hope this implementation isn’t kept around and treated as a quirk. This implementation is extremely unintuitive given their explanation of the expected behavior of CSS Nesting and the & symbol. To quote: The & signals to the browser “this is where I want the selector from outside this nest to go”. Their explanation and the actual implementation result…

With this hidden :is behavior, migrating to native CSS nesting from SASS will be extremely difficult.

Re: WebKit Supports Nested CSS

#168

Post by frosted-flakes »

toastal wrote: post #139
frosted-flakes wrote: post #56

Earlier quoted context omitted.

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.

You can enable :has in Firefox, but it's buggy and still very experimental at this point. Or at least it was a month or so ago.

Re: WebKit Supports Nested CSS

#169

Post by zestyping »

chrismorgan wrote: post #35
culi wrote: 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) {…

Relevant links on this: https://twitter.com/LeaVerou/status/1580215877705687040 , a poll about this specific matter (with links to other relevant polls which on the surface contradict this one). https://github.com/w3c/csswg-drafts/issues/7834#issuecomment... , on this exact matter (chosen as a convenient starting point, after matters were already settled, but the whole issue is about it). By the time this poll was do…

It's not a lot of code to implement, but it greatly simplifies usage by eliminating ambiguity:

- Easier for human readers (the "&" is an unmistakable visual indicator)

- Easier for human writers (fewer decisions; there's Only One Way To Do It)

- Easier for syntax colouring

Post reply on HN