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

161–170 of 170 posts

Re: Help choose the syntax for CSS Nesting

#161

Post by interstice »

hypertele-Xii wrote: post #115
culi wrote: post #81

Earlier quoted context omitted.

Eh. I kinda hate writing separate selectors just for a `:hover` I agree CSS has come a long way. Nested CSS is the one thing I'm waiting for before I completely abandon preprocessors. Think about the amount of characters wasted on having to write a whole separate rule to add a hover effect or something similar. Sure, better practices could usually make this unnecessary, but there's definitely valid situations for it.…

> Think about the amount of characters wasted on having to write a whole separate rule to add a hover effect or something similar. So... 20 bytes or so? A whopping 20 megabytes per a million websites. Seems like a very, very, very small optimization.

Every pseudo class * everything that needs that pseudo class * time taken to write/reason/check each one

Re: Help choose the syntax for CSS Nesting

#162

Post by culi »

adamwathan wrote: post #131
culi wrote: post #85

Earlier quoted context omitted.

that's great, but sometimes when I start vanilla side projects I like to take a CSS Zen Garden approach to things. That's harder to do the more tightly you couple your HTML and your CSS

The stylesheets for CSS Zen Garden examples are more tightly coupled to the HTML than any other CSS I've ever seen in my life. They literally have no use against any other block of HTML than that one page.

hmmmm. u right

Well still I shouldn't have to decorate my html for css to something I feel is pretty reasonable to expect it to support

Re: Help choose the syntax for CSS Nesting

#163

Post by somishere »

Sesse__ wrote: post #154
somishere wrote: post #151

Earlier quoted context omitted.

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

Yes, you need to support lookahead. But not unbounded. There are so many efficient ways to solve this problem. But computer says no?

Forget the idea that the tokeniser could place markers on semicolons / curly brackets to bound any future lookaheads. Why couldn't you just look one token ahead and analyse the potential pseudo-class/property. Pseudo-classes are clearly defined. There are about 50 of them. AFAIK none of them clash with property values. Keep it this way. If it's not a valid pseudo it's either an invalid selector or a property. Then you're just analysing the equivalent of a property value anyway.

---

Of course the above logic is flawed. I'm really just trying to tease out some useful information other than "can't be done".

I think the main challenge with this discussion is that the limitations of the parsers are not clear, at least outside circles directly working with them. Not only that, the explanations of why certain cases won't work are provided without the proper context needed to understand.

From what I understand tokenisation is dumb, it basically just spits out words. Without nesting it is straightforward for a parser to iterate over these tokens one by one, distinguishing between selectors and properties, based on prior context. Of course parsers could look ahead, but by design they don't, because efficiency.

The arguments for breaking the defacto nesting syntax (i.e. scss) seem to lie in the fact that the rules of the past must lie within the rules of the future, because graceful degradation.

Option C. - the most popular option, and also the most true to scss - while pragmatic in it's approach, is still shoehorning new into old.

I'm sure most agree that unbounded lookahead is probably not workable. But to make the argument that parsers can never look ahead, can never improve, seems ideological, if not ridiculous.

Re: Help choose the syntax for CSS Nesting

#164

Post by criswell »

Vinnl wrote: post #147
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.

I do wonder whether "no nesting" should've been an option in the poll. Not because I necessarily think it's the right option, but it might be: if this gets added to CSS, but people keep using other tools for easier nesting, then we're stuck with that implementation nonetheless.

I want to say this but too lazy to defend it.

Re: Help choose the syntax for CSS Nesting

#165

Post by toastal »

alwillis wrote: post #100
toastal wrote: post #94

Earlier quoted context omitted.

The biggest feature I miss from Sass is the indented syntax (though SugarSS does that better since it has multiline support); for now I make due even if semicolons and brackets add noise. There's still a use case for Sass if you need to build a CSS library and the loops and stuff is useful, but for general, contemporary CSS authoring, wanting to reach for loops and these extra features is a sign of a smell more so th…

> The biggest feature I miss from Sass is the indented syntax (though SugarSS does that better since it has multiline support); for now I make do even if semicolons and brackets add noise. Yes! The indented syntax is why I’ve stuck with Sass, Stylus and SugarSS for all these years for the same reasons you stated. But… I decided it was worth going back to plain CSS due to CSS Nesting and to simply my tooling.

lightningcss is my new preferred tool for doing all the vilification and prefixing.

Re: Help choose the syntax for CSS Nesting

#166

Post by int_19h »

Vinnl wrote: post #146
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…

Unfortunately, you would still have the problem of seemingly-arbitrarily needing `:is` in some cases, when the & isn't at the start of a declaration. So e.g. .someClass { :is(a) > & { font-weight: 700; } } instead of the more intuitive (but impossible) .someClass { a > & { font-weight: 700; } }

They need to just bite the bullet and devise something other than & to clearly distinguish nesting.

Re: Help choose the syntax for CSS Nesting

#167

Post by Vinnl »

int_19h wrote: post #166
Vinnl wrote: post #146

Earlier quoted context omitted.

Unfortunately, you would still have the problem of seemingly-arbitrarily needing `:is` in some cases, when the & isn't at the start of a declaration. So e.g. .someClass { :is(a) > & { font-weight: 700; } } instead of the more intuitive (but impossible) .someClass { a > & { font-weight: 700; } }

They need to just bite the bullet and devise something other than & to clearly distinguish nesting.

It's not the & that's the problem, it's the selectors that start with a regular letter or dash (i.e. `a` in my example above).

Re: Help choose the syntax for CSS Nesting

#168

Post by int_19h »

Vinnl wrote: post #167
int_19h wrote: post #166

Earlier quoted context omitted.

They need to just bite the bullet and devise something other than & to clearly distinguish nesting.

It's not the & that's the problem, it's the selectors that start with a regular letter or dash (i.e. `a` in my example above).

The point is that if & cannot consistently serve as a marker, then it shouldn't be one. Just add a different piece of syntax that always starts a nested rule and clearly disambiguates it and retain & solely to designate the parent.

Re: Help choose the syntax for CSS Nesting

#169

Post by Vinnl »

int_19h wrote: post #168
Vinnl wrote: post #167

Earlier quoted context omitted.

It's not the & that's the problem, it's the selectors that start with a regular letter or dash (i.e. `a` in my example above).

The point is that if & cannot consistently serve as a marker, then it shouldn't be one. Just add a different piece of syntax that always starts a nested rule and clearly disambiguates it and retain & solely to designate the parent.

Ah, so you're calling on people to vote for option 4 or 5?

Re: Help choose the syntax for CSS Nesting

#170

Post by chrismorgan »

alwillis wrote: post #160
nailer wrote: post #136

Earlier quoted context omitted.

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

That preprocessor variables are compiled out of existence is a feature. There are certainly situations where Custom Properties are useful, but if you don’t need that power, then using something simpler or inlining them out of existence produces results that are faster to run, use less memory, and are almost always smaller to ship.
Post reply on HN