Live data from Hacker News

WebKit Supports Nested CSS

webkit.org

31–40 of 183 posts

Re: WebKit Supports Nested CSS

#31
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…

  > come up with the cleanest, easiest-for-humans syntax as possible
I'm definitely on the opposite end of this argument. I really think browsers should be focusing on efficient and theoretically rock-solid foundations. The fact that web standards are slow to evolve and become adopted is a feature, not a bug. If you visit a create-react-app project from 2 years ago you probably couldn't get it running today. I would like a web where a hand-made site from a decade ago still works

The global web standard should be reliable and efficient. Syntactic sugars should be left to the ecosystems and only adopted when they don't confer performance tradeoffs

Re: WebKit Supports Nested CSS

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

Re: WebKit Supports Nested CSS

#33
post #24

Earlier quoted context omitted.

lol just curious what the thought process is. Sass and postcss support that and every other css flavor with nesting I've used supports it and it seems like it'd be a pretty big deal and something that would be explicitly called out in the article if it didn't support it. So I'm just curious if you've run into an issue with that or if there's some in-the-weeds technical reason why that might not be supported

My memory was correct. I found the section in the original proposal[1] that did not allow mixing nested rules and declarations: > When a style rule contains both declarations and nested style rules or nested conditional group rules, the declarations must come first, followed by the nested rules. Declarations occuring[sic] after a nested rule are invalid and ignored. [1] https://www.w3.org/TR/2021/WD-css-nesting-1-202…

Very interesting and exactly what I was curious about! Thanks for the links

Really curious about the reasoning behind that initial quirk

Re: WebKit Supports Nested CSS

#34
post #21

Whenever I see nested CSS, I always think the non-nested version is cleaner. Then again, I'm lucky enough to often work with my own 'hand-crafted', semantic html, and not some div soup generated by a tool.

I generally agree and wince at anything deeply nested, but there's no question that the biggest benefit here by far will be pseudoclasses. Especially when you wanna do something to children elements based on a pseudoclass .page form border: 2px solid #223; border-radius: 0.15rem; & button { background-color: red; transition: background-color 0.15s ease; } &:hover button { background-color: blue; } } seems way cleaner…

Yeah I agree. Most of my CSS files end up feeling like a big, append-only list of selectors for seemingly random stuff. Its so hard to tell if there are selectors in there that are no longer in use.

I really like the look of nested selectors for this reason - because I can group my selectors by component.

Re: WebKit Supports Nested CSS

#35
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 done, they had already decided not to consider mandatory-&, though I don’t really understand why (it’s pretty obvious to me that dividing into 3a and 3b would have been much more interesting than a couple of the other options which were straw men that no one was capable of taking seriously even if they tried).

https://github.com/w3c/csswg-drafts/issues/7961, about doing away with & in all cases for descendant selector (… which would be terrible for complexity and worst-case performance, and is only being considered because they already made things inconsistent by making & optional in every other case).

(I don’t like where it’s ended up, and consider requiring the & in all cases to be obviously materially superior, for both machine and human handling, and that there’s clear concrete advantage in having the requirement as an actual language rule rather than only a linter-enforced choice. People are far too hung up on exactly Sass syntax.)

> it would only make the parser's job easier

Mind you, it’s not a big difference; it’s just “if there’s no & in the selector, insert one and a descendant combinator at the start” in some shape, which could be as little as half a dozen lines of code net.

Re: WebKit Supports Nested CSS

#36

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.

The difficulty you mention is definitely an issue, but the insane repetition required for even a modestly complex piece of UI when using "flat" CSS is worse, in my opinion. I suppose there might even be a slight efficiency gain over the wire once Sass outputs nested CSS by default.

Re: WebKit Supports Nested CSS

#37
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) {…

I remember the main argument against this is that you can always enforce this with a linter and either way it's not a slower parser, maybe slightly more complex. Personally I do agree and I like the explicitness of always having the &

Yeah that's fair and I admit don't actually know anything about the parsing implications. I guess really I'm just looking for an excuse to convince my coworkers to adopt this practice without coming off like I'm bikeshedding haha

Re: WebKit Supports Nested CSS

#38
post #28
post #20

This half assed version of nesting is lame, as are all the others. Just give us SCSS its been ten years now, pave the cowpath.

What's the difference between this and SCSS nesting? It seems pretty full-featured to me. What's missing?

Yeah... the only difference _in terms of nesting_ that I'm aware of is exactly as discussed in the blog post: you must start a nested section with a symbol.

Sass itself has a huge amount of features... is the expectation that we should just adopt a Sass implementation into the browser or something?

Re: WebKit Supports Nested CSS

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

Post reply on HN