But option 3 from the previous poll is not the same as option 3 now...I don't understand
Help choose the syntax for CSS Nesting
31–40 of 170 posts
Re: Help choose the syntax for CSS Nesting
#32I like option 3 the best, but what I'd really prefer would be block-scoped css blocks that could optionally be scoped just to children of the parent tag. I know this is why we have shadow dom, but in practice I feel like the shadow dom has caused more problems than it solved. Now we have a bunch of ::part things being added to make up for the problems, but it's still very difficult to work with. I'd love to have the…
Have you looked into @scope?
Re: Help choose the syntax for CSS Nesting
#33So far, most of the responses are pretty underwhelming.
It's like that exercise middle school teachers sometimes do. They had out a worksheet where the directions tells the students to put their pencil down and do nothing. The rest of the worksheet is a series of questions or whatever.
80% of the students don't read the directions and start filling out the worksheet while the 20% who did read them are just sitting there.
That's what the feedback to an official CSS Working Group question has been like so far—people responding without having read the article; otherwise, they would know that…
1. Because of the way browsers work, the Sass syntax isn't an option—full stop.
The person who implemented Chromium's nesting support explains in the thread [1] why Sass's syntax is not an option. IMHO trying to revive a discussion about wanting the Sass syntax at this point is unproductive to say the least.
I've been using Sass and Stylus pretty much exclusively for a bunch of years—I get it. But that ship has sailed a long time ago, so let's not spend a lot of time on something that's not going to happen.
2. Perhaps before you respond, you should get up to speed on the issues at hand? There are links in the article you may want to read before you respond.
3. Here's what's arguably the most important thing to consider:
Which is best for the future of CSS? When people write CSS thirty years from
now — long after today’s habits and expectations are completely forgotten,
when future generations have never heard of Sass — which option will make writing
this language easy and elegant?
We weren't writing Sass 20 years ago (Sass made its appearance in 2006) and we won't be writing Sass 20 years from now [2].
If you think about it, nesting is one of the top reasons why devs use Sass today; once CSS nesting is enabled in all three browser engines, a lot of devs won't feel the need to keep using Sass for every project.
I know there are other features and workflows that Sass/Less/Stylus enable but as far as authoring stylesheets goes, nesting is huge.
This isn't like the old days when it took years before you could use new CSS in production—Chrome already has an implementation (I've used it) and once there's agreement on the syntax, I can't see why Apple, Google and Mozilla wouldn't be able to ship it Q1 2023.
So think about what's best for CSS and the web based on where things are headed—this isn't about you. Okay, it's not entirely about you and your team; but it's mostly about us— current and future web developers.
We're going to need to live with this choice for many years to come.
Let's not screw this up.
[1]: https://news.ycombinator.com/item?id=34007053
[2]: To be pedantic for a second (this is Hacker News after all ;-)), yes, someone will have to work on some legacy codebase 20 years from now that has thousands of lines of Sass… I get that. But we're getting close to a point in time where the vast majority of new web projects will not need to use Sass.
Re: Help choose the syntax for CSS Nesting
#34I'd say they should avoid bloating CSS, keep Sass style and just use type='text/sass' or type='text/css-nested' in the style tag, but it seems that attribute is depreciated... why is that?
How about a new file extension. .css2 or.xcss or something?
Re: Help choose the syntax for CSS Nesting
#35> 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…
Do you have any numbers on that? On a modern computer, I'm having trouble believing that the time difference would be noticeable to a human. Seems like parsing even a few megs of CSS would be measurable in milliseconds?
Re: Help choose the syntax for CSS Nesting
#36Could a backwards parser work? With the Sass syntax I think doing the parsing backwards can be made without lookahead. Probably it has other issues though...
Re: Help choose the syntax for CSS Nesting
#37So far, most of the responses are pretty underwhelming. It's like that exercise middle school teachers sometimes do. They had out a worksheet where the directions tells the students to put their pencil down and do nothing. The rest of the worksheet is a series of questions or whatever. 80% of the students don't read the directions and start filling out the worksheet while the 20% who did read them are just sitting th…
I read the whole thing. And I don’t care if it doesn’t work or what excuses they make.
If it’s not gonna be similar to any existing implementation for doing css then don’t bother doing it.
The last thing we need is a shit version of nesting. The syntax we have now is good, it’s what we know, it works. There’s no need for stupid filler syntax to work around scenarios. I.e prefixing with @nest.
Re: Help choose the syntax for CSS Nesting
#38Earlier quoted context omitted.
Did you read the third paragraph in the article?
I think the question that's not answered clearly is: why can Sass parse it, but browsers can't? It says: "If they see a sequence like element:pseudo, they’ll parse the entire style rule as if it were a property: value declaration.", but why can't the parser be modified to work like Sass parser? Maybe it's obvious for someone who has deep parser knowledge, but for someone who only has a superficial knowledge, this is…
See the comment at https://news.ycombinator.com/item?id=34006622
Re: Help choose the syntax for CSS Nesting
#39Earlier 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?
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 mod…
Understood. But if the idea was for a 'strict' syntax? i.e. in order to make use of newer syntax rules, CSS would need to declare itself as such and be formatted per spec (and would fail to parse otherwise, same as now), negating the need for "infinite lookaheads" per the explainer. So it's more like a switch statement than multiple engines. CSSOM is straightforward this way, you're dealing with strict by default. Inline styles the same.
Re: Help choose the syntax for CSS Nesting
#40> 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…
To elaborate why you need unlimited lookahead, consider the following:
h1:has(+ p) { something: anything; } h1 { something: nothing; }
everything: has(+ p) { something: anything; }; h1 { something: nothing; }
That said, the main problem is that the property syntax is overly forgiving, not that the nested rule syntax is problematic. Something akin to JS `use strict` should be able to restrict the property syntax enough to allow the nested rule syntax without unlimited lookahead.