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

151–160 of 183 posts

Re: WebKit Supports Nested CSS

#151

Post by doodlesdev »

satao wrote: post #117
EMIRELADERO wrote: post #13

I don't know anything about WebKit development processes or community management, so please forgive me if I say something wrong. Isn't it interesting how the engine has been implementing new features and generally running on a lot of steam coincidentally since the EU's Digital Markets Act (which will force other web engines on iOS) went into effect? Or maybe the dev process and community interactions has always been…

Historically the webkit team has pushed the web possibilities a lot. Just take a look at the amount of APIs that you had to add the `webkit` prefix, for example. Not sure if you work with browsers, but constantly you meet something that they implemented first. I honestly think that developers are very wrong when they think that Safari/webkit is slowing the web down. Yes, some things like lack of notifications etc are…

It's not just getting those features implemented, but also shipping those to the user. Safari is the only browser that doesn't have autoupdate and has versions tied an operating system in 2023 and that's one of the biggest problems.

While you can be happy only supporting say the last version of all other browsers, Safari requires you to give it years before the marketshare of the new versions are enough that you can migrate to new features, thus making the fact that webkit had implemented those features first completely irrelevant.

Furthermore, the fact it only runs macOS makes it a true pain in the ass to test, you need to have access to an apple machine to test it, be it virtualized or remote, which sucks because even Edge has support for Linux at this point.

Even worse is the fact that there are indeed a lot of features Apple simply refuses to implement, specially related to PWAs, which has slowed down the adoption of PWAs by at least 20 years, ane that's if they ever make a comeback after the crippling Apple did to them to maintain App Store supremacy.

I could go on and on and on and on. Webkit is great sometimes, but Safari absolutely sucks and has been slowing down web development ever since IE stopped being a problem for most developers.

Re: WebKit Supports Nested CSS

#152

Post by kerkeslager »

chrismorgan wrote: post #128
kerkeslager wrote: post #121

Can someone explain why parsers can't handle nested selectors which don't start with a symbol? I've written plenty of parsers (recursive descent, packrat, Pratt, and using generators) and not a single one would have any trouble parsing something like: html { body:has(p) { width: 1000px; } } The only thing I can think of is that they are trying to avoid a lookahead, i.e. you have selectors like "body:has(p) {" which i…

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 I care about.

Is there any conflict with anything that exists in the standard right now?

Re: WebKit Supports Nested CSS

#153

Post by rawling »

culi wrote: post #21
LAC-Tech wrote: post #15

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…

Any way to turn the second use of `button` into a second level of nesting there?

E: or would you have to use `>` somehow?

Re: WebKit Supports Nested CSS

#154

Post by Sesse__ »

c-smile wrote: post #131
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.

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 about Gecko or WebKit, but at least in Blink they're handled entirely different. And @scope (which is the closest I know of to your hypothetical @set) is significantly less efficient than bucketing is, or even a simple parent selector, since it needs to walk up the DOM after the rule matched.

Re: WebKit Supports Nested CSS

#155

Post by Sesse__ »

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.

The flag you're looking for is --enable-blink-features=LayoutNGSubgrid, I assume.

Re: WebKit Supports Nested CSS

#156

Post by TabAtkins »

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…

Notably, this is identical to the behavior you get from @scope's nesting, and from passing a complex selector to an `el.querySelector()`.

(We discussed adopting Sass's behavior in https://github.com/w3c/csswg-drafts/issues/8310#issuecomment...> but ultimately dropped it.)

Re: WebKit Supports Nested CSS

#157

Post by TabAtkins »

culi wrote: post #33
frosted-flakes wrote: post #30

Earlier quoted context omitted.

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

Depending on the exact parsing strategy it might be genuinely required (such as if the parser switches from "property mode" to "rule mode" at some point), but in this case it was just because it's kinda confusing to do so.

We removed the restriction, but still warn against it due to readability issues.

Re: WebKit Supports Nested CSS

#158

Post by TabAtkins »

somishere wrote: post #67

Sanity has prevailed! Great work from the WebKit team, leading the way here. Not to mention great solve on the `color: blue` fiasco. Balances an edge-case compromise nicely, and leaves it open to future improvements. Bravo.

Fwiw, while I deeply appreciate WebKit supporting the proposal as well, the editors of the Nesting spec are Googlers and the Chrome impl happened at the same time.

Re: WebKit Supports Nested CSS

#159

Post by AltruisticGapHN »

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.

You should use stylelint anyway and then you can set `max-nesting-depth`

https://stylelint.io/user-guide/rules/max-nesting-depth/

I mean, these days almost every JS developer use some kind of linter - why would you not use a linter for CSS? Literally nothing to lose since you can set the rules as relaxed as you want.

PS: I set it to 3 - Using good convention like SuitCSS I have never found I needed more nesting. Usually you think about a problem and find a simpler way to do it.

https://github.com/suitcss/suit/blob/master/doc/naming-conve...

TLDR If you use any of the good practices for CSS such as BEM or BEM-like you don't have lots of nesting anyway.

And I like how the article mentions as an example `ul article ul` and how to solve it by adding a symbol :is() to be able to nest, and it's literally the one thing you don't want to do anyway, which is a selector like `ul article ul` (as per BEM methodology). Instead `.list .article .article-list` as a veyr poor example doesn´t need the special "fix" the article mentions.

Re: WebKit Supports Nested CSS

#160

Post by __ryan__ »

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 in a majorly different CSS selector.

The implemented functionality, however useful, makes no sense as a default if one can explicitly use :is to achieve this behavior like below.

    .foo .bar {
        .baz :is(&) {
        }
    }
The default should behave like they claim it does; simply replace & with the “outside” selector.
Post reply on HN