Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Help choose the syntax for CSS Nesting

webkit.org

Post reply on HN
Print view View original

11–20 of 170 posts

Re: Help choose the syntax for CSS Nesting

#11

Post by Sesse__ »

slinger wrote: post #5

> Everyone wishes CSS nesting could use the same kind of simple syntax that Sass does. That’s impossible, however, because of the way browser parsing engines work. I wish browser vendors could work around this limitation and stick to Sass syntax. IMHO all of those options seems strange and make it difficult to read.

> I wish browser vendors could work around this limitation and stick to Sass syntax.

FWIW, it is not a limitation, it's a conscious choice. If you want to accept arbitrary selectors in option 3, you'll need unlimited lookahead, which limits the types of parser algorithms you can use, which means that _all CSS_ (not just CSS using nesting, every single web page out there) will be slower to parse, which means the web will become ever so slightly slower. And you cannot ever go back after making that choice. Is it really worth it for the few unusual cases that require workarounds, in an already not-super-common feature?

(Disclaimer: I wrote Chromium's CSS nesting support. It currently implements option 3.)

Re: Help choose the syntax for CSS Nesting

#12

Post by derkades »

LordDragonfang wrote: post #7

Option 3 seems the most intuitive, but I can see the arguments for 5. It's 4 that I'm having a hard time understanding why anyone would want it that way. It's truly awful. I can't think of literally any other language (style, markup, programming, or otherwise) that does nesting with a second set of adjacent (not nested!) curly braces.

LaTeX maybe? But yes, I agree that it's awful.

Re: Help choose the syntax for CSS Nesting

#13

Post by somishere »

Sesse__ wrote: post #11
slinger wrote: post #5

> Everyone wishes CSS nesting could use the same kind of simple syntax that Sass does. That’s impossible, however, because of the way browser parsing engines work. I wish browser vendors could work around this limitation and stick to Sass syntax. IMHO all of those options seems strange and make it difficult to read.

> I wish browser vendors could work around this limitation and stick to Sass syntax. FWIW, it is not a limitation, it's a conscious choice. If you want to accept arbitrary selectors in option 3, you'll need unlimited lookahead, which limits the types of parser algorithms you can use, which means that _all CSS_ (not just CSS using nesting, every single web page out there) will be slower to parse, which means the web w…

Possibly a stupid question. But is there a reason you couldn't include 2 engines? And require e.g. a doctype assertion?

Re: Help choose the syntax for CSS Nesting

#14

Post by halostatue »

LordDragonfang wrote: post #7

Option 3 seems the most intuitive, but I can see the arguments for 5. It's 4 that I'm having a hard time understanding why anyone would want it that way. It's truly awful. I can't think of literally any other language (style, markup, programming, or otherwise) that does nesting with a second set of adjacent (not nested!) curly braces.

Same. I think that the only thing I don’t like about 3 is the need for `:is(aside)` and the like, and I can see that there might be some performance benefit to `@nest {…}` blocks (5). I think the only thing I don’t like about 5 is the required `& {}` block.

I find 5 to be the most consistent and 3 to be mostly cleaner because of what becomes optional.

Re: Help choose the syntax for CSS Nesting

#15

Post by Klonoar »

somishere wrote: post #13
Sesse__ wrote: post #11

Earlier quoted context omitted.

> I wish browser vendors could work around this limitation and stick to Sass syntax. FWIW, it is not a limitation, it's a conscious choice. If you want to accept arbitrary selectors in option 3, you'll need unlimited lookahead, which limits the types of parser algorithms you can use, which means that _all CSS_ (not just CSS using nesting, every single web page out there) will be slower to parse, which means the web w…

Possibly a stupid question. But is there a reason you couldn't include 2 engines? And require e.g. a doctype assertion?

Because it's the same result as if you just included the slower one, since there's mindshare for the SASS variant already - it'll just become defacto standard, and slow down the web.

The line in the sand here is good.

Re: Help choose the syntax for CSS Nesting

#16

Post by wnevets »

slinger wrote: post #5

> Everyone wishes CSS nesting could use the same kind of simple syntax that Sass does. That’s impossible, however, because of the way browser parsing engines work. I wish browser vendors could work around this limitation and stick to Sass syntax. IMHO all of those options seems strange and make it difficult to read.

> stick to Sass syntax. IMHO all of those options seems strange and make it difficult to read.

That is my biggest take away from this whole thing. The SASS/LESS syntax is so much easier to read to me.

Re: Help choose the syntax for CSS Nesting

#17

Post by karaterobot »

gorkish wrote: post #9

We want it to work the way Sass works. FFS make it happen and stop it with all this pedantry.

I want it to work the way Stylus works, because Stylus syntax is better (fight me), but I will accept Sass and its unnecessary braces as an improvement over current CSS for sure!

Re: Help choose the syntax for CSS Nesting

#18

Post by Sesse__ »

somishere wrote: post #13
Sesse__ wrote: post #11

Earlier quoted context omitted.

> I wish browser vendors could work around this limitation and stick to Sass syntax. FWIW, it is not a limitation, it's a conscious choice. If you want to accept arbitrary selectors in option 3, you'll need unlimited lookahead, which limits the types of parser algorithms you can use, which means that _all CSS_ (not just CSS using nesting, every single web page out there) will be slower to parse, which means the web w…

Possibly a stupid question. But is there a reason you couldn't include 2 engines? And require e.g. a doctype assertion?

If nothing else, it would strongly increase maintenance and testing costs. You also have the usual problems of cut-and-paste between examples and stylesheets not necessarily working as you'd expect. Then there's the subtle issue like how you'd serialize such things from CSSOM (JavaScript); which parser mode would you use? How would you serialize something “unsupported” in one mode that was created by CSSOM? Which mode would inline style attributes use?

Re: Help choose the syntax for CSS Nesting

#20

Post by somishere »

Klonoar wrote: post #15
somishere wrote: post #13

Earlier quoted context omitted.

Possibly a stupid question. But is there a reason you couldn't include 2 engines? And require e.g. a doctype assertion?

Because it's the same result as if you just included the slower one, since there's mindshare for the SASS variant already - it'll just become defacto standard, and slow down the web. The line in the sand here is good.

I guess the idea would be something along the lines of a 'strict' tag, to identify a shift to modern syntax with stricter rules around parsing, that ensures an infinite lookahead wouldn't be required for e.g. pseudos vs properties.

I put together a regex last time this was discussed [1] (which obviously completely alleviates all concerns): https://regex101.com/r/aOc2Pz/1

But seriously, syntax evolutions happen. If there's an issue with parsing garbage CSS why not just let that garbage run slowly, and re-optimise for the rest, prioritising for form and function.

[1] https://news.ycombinator.com/item?id=32248837

Post reply on HN