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

121–130 of 183 posts

Re: WebKit Supports Nested CSS

#121

Post by kerkeslager »

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 initially look like they could be setting a "body" attribute to the value "has" until you reach the "(". But these lookaheads aren't hard to implement in practice. There are performance issues if the lookahead has to go too deep, but CSS developers can use the & in those cases as an optimization, and you could limit lookahead depth to something like 256 (which would handle the vast majority of non-malicious use cases).

Perhaps the lookahead has a lot more drastic effect than I'm expecting on performance for short lookaheads, but I'd like to at least see some profiling of that, as it seems to me like this possibility was discarded without much consideration or explanation (it wasn't even included in the poll).

There's also another way to do this without lookaheads at all, by building up a structure for each potential path and then discarding the one that doesn't complete (I think this is basically a DFA but it's been a while since I read literature on this so I'm forgetting the terminology). This would probably avoid the performance issues but also probably be a larger departure from the current implementation of the parsers.

Re: WebKit Supports Nested CSS

#122

Post by ramesh31 »

azangru wrote: post #115
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) {…

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

Re: WebKit Supports Nested CSS

#123

Post by robgibbons »

a1371 wrote: post #5

Awesome to finally have nesting. The way I see it, this took 10 years longer than it should have. I feel the only big thing missing from the vanilla stack for me right now is a template element that multiple html files can share. Just like how you make a blog header in Jekyll or Hugo and it adds it on all your blog posts get the header. I haven't found an easy way of doing that if I have a bunch of html pages.

What you're asking for is called Server-Side Includes, it's been a feature of Apache for ages, but is also supported by Nginx and other servers.

Re: WebKit Supports Nested CSS

#124

Post by tehbeard »

amjnsx wrote: post #106
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

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?

Re: WebKit Supports Nested CSS

#125

Post by meerita »

dgb23 wrote: post #97
meerita wrote: post #96

That's a valuable addition, but it's unfortunate that it arrived late. These days, functional CSS http://minid.net/2019/04/07/the-css-utilitarian-methodology/ is gaining popularity due to its effectiveness in reducing the need for excessive nesting of classes and unwieldy CSS files.

Functional/atomic css is great. But there are many use cases for composing and refactoring them into aggregates. Nested css can help you for tgese cases.

The more you rely on CSS to change the visuals based on situations, the worst to main in the future. It's an option, that's good, but for me it's been years that I don't go back to that anymore.

Re: WebKit Supports Nested CSS

#126

Post by hbn »

suprfnk wrote: post #63
irrational wrote: post #61

Earlier quoted context omitted.

I’m looking forward to the day when we can get back to no compiling/transpiling web development.

I'm afraid TypeScript support in browsers is very far away, if it ever happens.

There's not much of a point. It'd just slow movement on Typescript itself. Unless of course fast-moving, transpiled Typescript started being transpiled to browser-acceptable Typescript, i.e. transpiled back enough to where most browsers can parse it. But at that point, why not just do it the way we're currently doing it, targeting JavaScript? Also it'd just make web dev even more confusing for newcomers than it already is.

I don't really see an issue with treating JavaScript as something of an "assembly of the browser," in that anyone can make their own language and target it.

Re: WebKit Supports Nested CSS

#127

Post by maattdd »

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…

Indeed, the reason is simply to keep the current look-ahead(1) for the CSS syntax. If you allow nested rules with selector list which doesn't start with a symbol, you need (in theory) an unbounded look-ahead.

However, the current spec has been written in a way that it doesn't prevent removing this restriction in the future. But the CSSWG would prefer to have some real world profiling data to know the actual performance cost of removing this restriction.

Re: WebKit Supports Nested CSS

#128

Post by chrismorgan »

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, which I think was where things started going wrong.)

Re: WebKit Supports Nested CSS

#130

Post by tommica »

scambier wrote: post #66
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.

"For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software."

For those that do not know what this refers to: https://news.ycombinator.com/item?id=8863
Post reply on HN