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

91–100 of 170 posts

Re: Help choose the syntax for CSS Nesting

#91

Post by franciscop »

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…

Optional and being able to require it with e.g. a linter on a per-project basis seems better idea for me, since I'd strongly prefer not using & and for the vast majority of cases (as we learned from SASS) it's not needed.

Re: Help choose the syntax for CSS Nesting

#92

Post by wnevets »

culi wrote: post #82
wnevets wrote: post #16

Earlier quoted context omitted.

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

I don't really get how tbh. Isn't Option 3 the exact same thing as Sass except the "&" is required in a few more places than it is in Sass? It's also optional in Sass so I already write that way (always using the "&") personally

I never use & when I am only nesting. So when I am skimming code quickly and I see an & I immediately know there is something else happening besides a nesting, for example &:hover.

This is probably something I can unlearn but until then it is very jarring to see & everywhere.

Re: Help choose the syntax for CSS Nesting

#93

Post by culi »

notpushkin wrote: post #90
culi wrote: post #82

Earlier quoted context omitted.

I don't really get how tbh. Isn't Option 3 the exact same thing as Sass except the "&" is required in a few more places than it is in Sass? It's also optional in Sass so I already write that way (always using the "&") personally

Most of the time, yeah, but there's a corner case (example C from the article): a:hover { color: hotpink; :is(aside) & { color: red; } } Here, you can't just use `aside &` as this starts with a letter and will confuse the parser. Hence, wrapping with `:is()` is requires.

Tbh, if this sort of "nesting" is possible in Sass, I don't think I've ever used it...

Is it really necessary to support? I'd be cool with just simple nesting logic

Re: Help choose the syntax for CSS Nesting

#94

Post by toastal »

alwillis wrote: post #83
toastal wrote: post #77

Earlier quoted context omitted.

I've stopped using preprocessor for years now. Almost everything I need is now in the spec or solved ‘good enough’ through a naming scheme. IMO, a preprocessor is a lot of complexity for little gain currently.

> I've stopped using preprocessor for years now. I decided to not use Sass on my latest project; feels like CSS is at the point where I didn't need it any more. CSS has come a long way.

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

Re: Help choose the syntax for CSS Nesting

#95

Post by notpushkin »

culi wrote: post #93
notpushkin wrote: post #90

Earlier quoted context omitted.

Most of the time, yeah, but there's a corner case (example C from the article): a:hover { color: hotpink; :is(aside) & { color: red; } } Here, you can't just use `aside &` as this starts with a letter and will confuse the parser. Hence, wrapping with `:is()` is requires.

Tbh, if this sort of "nesting" is possible in Sass, I don't think I've ever used it... Is it really necessary to support? I'd be cool with just simple nesting logic

It is definitely possible, just with a more complicated (and slow) parser than what browsers use now – there's been some discussion in this thread.

As for whether it's necessary – eh, it's neat and might be useful sometimes but it's not a big deal I think. Personally, I remember a couple instances when I needed to override a few properties depending on context and it would be helpful, but `&:hover` is so much more useful.

Re: Help choose the syntax for CSS Nesting

#96

Post by mattwad »

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…

I don't know, I have been using SASS/LESS for a while and I almost never use the & because 95% of the time, I am talking about a descendant when I use nesting. I think it would be very easy to accidentally typo or miss in a review the difference between "& .sub-class" and "&.sub-class."

Re: Help choose the syntax for CSS Nesting

#97

Post by frivoal »

somishere wrote: post #20
Klonoar wrote: post #15

Earlier quoted context omitted.

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

The reason why this cannot be done is documented in the csswg's informal FAQ: https://wiki.csswg.org/faq#versioning-css-fixing-design-mist...

Re: Help choose the syntax for CSS Nesting

#99

Post by bongobingo1 »

franciscop wrote: post #91
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…

Optional and being able to require it with e.g. a linter on a per-project basis seems better idea for me, since I'd strongly prefer not using & and for the vast majority of cases (as we learned from SASS) it's not needed.

Q for Smarter people than me with more experience: is it better to require stricter upstream and loosen the downstream (so would require &, and MyCSS framework could insert them where needed) or looser upstream and tighten local code with linters?

"be conservative in what you do, be liberal in what you accept from others" applies?

Re: Help choose the syntax for CSS Nesting

#100

Post by alwillis »

toastal wrote: post #94
alwillis wrote: post #83

Earlier quoted context omitted.

> I've stopped using preprocessor for years now. I decided to not use Sass on my latest project; feels like CSS is at the point where I didn't need it any more. CSS has come a long way.

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.

Post reply on HN