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

151–160 of 170 posts

Re: Help choose the syntax for CSS Nesting

#151

Post by somishere »

Sesse__ wrote: post #141
somishere wrote: post #130

Earlier quoted context omitted.

The difference isn't the separator, it is the suffix. Strict designation would afford that either properties be signed off with a semi-colon on the same line (or just a newline). Alternatively you could go the other way and enforce selector signoff with a comma or a bracket on the same line. No strict, no nesting /newfangled wizardy. This allows for graceful degradation. My point about corner cases is that there is v…

Once you start looking at the suffix to disambiguate what the first token means, you're already in the more-than-one-token lookahead land, which is what we're trying to avoid in the first place. CSS property declarations already need to be signed off with a semicolon on the same line. If not, the entire declaration is ignored (this is specified in the CSS standard, and if you don't implement it correctly, you will br…

I'm sorry but I thought the challenge as described was one of "infinite lookahead"? Similarly, the csswg profer "graceful degradation" as the reason why a declaration isn't workable. But this solution clearly doesn't require infinite lookahead. It also degrades gracefully.

In fact lookahead isn't needed at all, except in (exceptionally) rare cases. Is the problem that the parsers are incapable of using any smarts beyond what is already provided?

Am I missing something?

Aside: Good point on the semicolon! I think in the previous discussion someone was making the point that parsers are exceptionally flexible/forgiving re. weird and wonderful line break and spacing combos. I wasn't sure about the status of semicolon usage. Idea of strict would just be to put an end to that.

Edit: and hey, apologies for labouring the point on this. But I am genuinely interested. I feel like these conversations just always end up in "you wouldn't understand" territory.

Re: Help choose the syntax for CSS Nesting

#152

Post by [deleted] »

lifthrasiir wrote: post #40
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…

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; } Syntactically speaking these two lines are equivalent except for a single semicolon; the differing first token doesn't change anything about that. And you can absolutely add a custom element that looks like a pr…

[deleted]

Re: Help choose the syntax for CSS Nesting

#153

Post by somishere »

lifthrasiir wrote: post #40
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…

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; } Syntactically speaking these two lines are equivalent except for a single semicolon; the differing first token doesn't change anything about that. And you can absolutely add a custom element that looks like a pr…

First up, anything starting with a .#* is a selector. Secondly, if you're selective about valid tokens then how many tokens are both a valid selector and property name? Probably custom only? And the number of times you'd find a pseudo selector on one of these? We're rapidly approaching extreme edge case territory here.

Also, looking at your second line: I would say the second part (starting at the semicolon before the h1), is invalidated by the semicolon. No need to lookahead or read up to the semicolon. The first part would always be evaluated first, up to the closing curly bracket. The second part would fail at the first character. I'm looking at this on a phone so maybe I've misread?

Edit: I should add, I'm not disagreeing with your point (I don't think!), just emphasising it

Re: Help choose the syntax for CSS Nesting

#154

Post by Sesse__ »

somishere wrote: post #151
Sesse__ wrote: post #141

Earlier quoted context omitted.

Once you start looking at the suffix to disambiguate what the first token means, you're already in the more-than-one-token lookahead land, which is what we're trying to avoid in the first place. CSS property declarations already need to be signed off with a semicolon on the same line. If not, the entire declaration is ignored (this is specified in the CSS standard, and if you don't implement it correctly, you will br…

I'm sorry but I thought the challenge as described was one of "infinite lookahead"? Similarly, the csswg profer "graceful degradation" as the reason why a declaration isn't workable. But this solution clearly doesn't require infinite lookahead. It also degrades gracefully. In fact lookahead isn't needed at all, except in (exceptionally) rare cases. Is the problem that the parsers are incapable of using any smarts bey…

> But this solution clearly doesn't require infinite lookahead.

It clearly does? There can be an infinite number of tokens before you see the semicolon and know what you're parsing. The page contains examples of this, or you can dig into those bug threads.

> In fact lookahead isn't needed at all, except in (exceptionally) rare cases.

“You don't need to support lookahead, except sometimes” really means “you need to support lookahead”. And that changes how your parser and tokenizer has to work (in particular, you need to be capable of saving a potentially infinite amount of tokens in case you need to rewind). You don't get around that by saying it's rare.

Re: Help choose the syntax for CSS Nesting

#155

Post by isleyaardvark »

alwillis wrote: post #33

So 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…

Saying we’ll live with this decision for 20 years and we shouldn’t screw this up is a very strong argument for a “none of the above” option.

Re: Help choose the syntax for CSS Nesting

#156

Post by zamadatix »

alwillis wrote: post #60
CSSer wrote: post #54

Wow. I’m really surprised so many people have voted for option 3 so far. Option 5 feels much more in line with the rest of the other proposals and features in CSS, and option 3 introduces at least one quirk we’ll have to internalize and teach to everyone forever. Those suck. I have to teach those kinds of things to juniors until my throat is sore some days. I don’t have much of substance to say about option 4 other t…

Thanks for the thoughtful response. No. 3 is the knee jerk, in the heat of the moment response; but no. 5 makes the most sense long term.

Option 5 is more structured but Option 3 is faster for a person to work with. I don't think either approach is necessarily more "long term" than the other unless there is another tradeoff I'm missing neither is an invalid thing to optimize the long term for.

Having to go back and modify the existing non-nested lines when you just want to add a nested declaration seems like a large source of "oh damn it" errors and twiddling when you are progressively building/testing styling. The same with wanting to keep default and pseudo-class attributes close to each other for human convenience.

Re: Help choose the syntax for CSS Nesting

#157

Post by asd11 »

jasonhansel wrote: post #50

I prefer Option 3, but IMHO the "&" should be required in all cases. Having it present in some places and absent in others makes the resulting code less readable, more ambiguous, and generally harder to understand. I'd rather keep things simple and uniform, even if it costs extra keystrokes. Also: it would allow things like ".a { &.b { x: y; } }" (which would be equivalent to ".a.b { x: y; }") to be clearly different…

Get WhatsApp live

Re: Help choose the syntax for CSS Nesting

#158

Post by mekster »

joeydi wrote: post #26

I think the reason this debate continues to rage on is that all of the options are worse than what is currently available with pre-processors. If CSS can’t match or improve on the obvious syntax used by sass then they should not implement it. All of these options are confusing. Nesting is not a requirement for CSS. Just let it go and if you want nesting use sass.

For sake, Stylus doesn't even require colons and semicolons with plenty more features that was invented more than a decade ago and CSS is still trying to sort out things that was solved in 2010 in worse ways in 2022?

This is beyond comprehensible. I guess I can never let go of preprocessors.

Re: Help choose the syntax for CSS Nesting

#159

Post by LudwigNagasena »

alwillis wrote: post #111
LudwigNagasena wrote: post #103

Earlier quoted context omitted.

Everything is still going to be tree-shaken, minified and mangled before being transferred to the client; no matter how much bells and whistles are added to web languages. Why not just make it decoupled and efficient? Compiling code isn't a radical idea.

As pointed out in the article, the nesting syntax has to work in every setting that CSS works in today and has always worked in—from a hobbyist working alone on a side project to teams working on huge code bases and everything in between. Because of the universality of the web, anyone from a kid in a developing country with a netbook and a text editor to teams at Fortune 500 companies need to be able to author CSS. I…

> As pointed out in the article, the nesting syntax has to work in every setting that CSS works in today and has always worked in—from a hobbyist working alone on a side project to teams working on huge code bases and everything in between.

Yeah, and I’m saying it shouldn’t work anywhere at all.

> Because of the universality of the web, anyone from a kid in a developing country with a netbook and a text editor to teams at Fortune 500 companies need to be able to author CSS.

Compiling messy unoptimized code into efficient code is somehow bad for kids with netbooks? I don’t follow.

> It's a non-starter to require all kinds of tooling—preprocessors, compilers, task runners, packagers, etc. to create web content. You can use these tools if it makes sense for a particular situation but it should always be optional.

Why? So the whole modern world should be stuck with outdated decisions from 1980s and be horribly inefficient because there is one kid in Djibouti who can’t download VSCode and learn to click F5 to compile things?

> BTW, browsers already use Just In Time compilers [1] to render CSS as efficiently as possible; all of the tooling you mentioned is mostly to reduce the size of CSS payloads over a network. Regardless if you minify CSS or not, its rendering speed isn't going to change.

Yet they are still unable to implement Sass syntax. So why not just get rid of this fundamental limitation that just makes no sense and that barely made sense even 10 years ago?

Re: Help choose the syntax for CSS Nesting

#160

Post by alwillis »

nailer wrote: post #136
alwillis wrote: post #89

Earlier quoted context omitted.

> I want browsers to have first class Sass support. We don't want that. For example, CSS Custom Properties (CSS variables) are far more powerful than Sass variables. Plus you'd have two different implementations for how variables work—CSS variables work with the cascade but Sass variables don't. You can't have two fundamentally different methods for variables. That's a non-starter. Pretty much all of the good stuff f…

> We don't want that. Statistically, we do. Sass won the precprocessor wars and nearly every developer prefer SCSS variables over the var(--oh-god) that is CSS syntax. > For example, CSS Custom Properties (CSS variables) are far more powerful than Sass variables. Vague. How are they more powerful? Does that offset their downside? > Pretty much all of the good stuff from preprocessors is going to be implemented in CSS…

> Statistically, we do. Sass won the precprocessor wars and nearly every developer prefer SCSS variables over the var(--oh-god) that is CSS syntax.

This isn't about which preprocessor is the most popular; it's about the syntax that's going to be used for CSS that we're going to have to live with for a long time.

Look, best practices come and go. Table-based layouts, 960 grid [4], Dreamweaver, special hacks for IE6—we don't do those things any more. With all of the enhancements that have already been added to CSS (CSS Grid, Flexbox, Container Queries, :has() parent selector) and the ones coming—CSS nesting, style queries, conditional, new/better color spaces—using Sass will seem as old-school as including jQuery in every project in a few years.

To quote Denzel Washington's character in the movie Training Day: "We don't roll that way any more." [5]

If you want to go on using Sass, then nothing changes for you; you can even use custom properties in your Sass files. It's not an all or nothing situation.

> How are they more powerful? Does that offset their downside?

Seriously?

There's no functional downside compared to the alternative. The syntax isn't bad once you understand what's going on, but that's subjective anyway. Even if you don't love the syntax, the functionality they enable for developers more than makes up for that.

Sass variables are just static placeholders for values; they're just a step above doing a search and replace in an editor. Very handy when Sass was developed 16 years ago, but very limiting today.

The real question can the dynamic web experiences people come to expect be done only using Sass variables? Are taking full advantage of everything the web platform has to offer by only using Sass variables? The answer is no in both cases.

- they're not part of the DOM and they can't be accessed via JavaScript

- they can't be changed at runtime, such as responding to media queries or other state changes

- can't be used for passing values to and from web components

There are dozens of articles about why custom properties are superior to preprocessor variables:

[1]: https://css-tricks.com/difference-between-types-of-css-varia...

[2]: "Practical Use Cases For CSS Variables"—https://ishadeed.com/article/practical-css-variables/

[3]: "DRY Switching with CSS Variables: The Difference of One Declaration"—https://www.codeinwp.com/blog/css-variables/

[4]: https://960.gs

[5]: https://movie-sounds.org/ghetto-movie-sound-clips/quotes-wit...

Post reply on HN