Which nowhere else is made clear that multiple nested selections can be used within the block, so I would advocate changing examples to this style formatting:
I understand the reasoning behind the nesting selectors however would a different character be possible?
What that might be I’m not sure as the following are all likely out: []<>()*@+"': backticks perhaps or slashes?
Square brackets look good to me; since it’s essentially an array of objects (looking at the JavaScript syntax). On the other, curly brackets look more natural in CSS.
I think the square brackets stand out more and thus make it more readable; it triggers the brain with a “Hey this is new” sort of vibe. Not sure if this would play nice with the attribute selector, maybe @tabatkins can enlighten us?
No problem; this isn’t in a context that already expects selectors, so there’s no clash syntactically. (That said, I still prefer curlies, for consistency.
Yes, the same debate is had in every preprocessor that supports nesting. In general, the advice seems to be to follow the Inception rule - four layers is too deep.
Eh, that’s what bracket-matching in your IDE is for.
I think the different sigil makes a lot of sense as it doesn’t really mean the same thing does it.
I thought you were not happy with using the same characters again to keep CSS parsers simple.
These all should be possible right (Not that I think I like any of the options or square more for that matter)?
And IDK why. But I really don’t mind the curly braces.
Here’s another idea:
Perhaps we could have something that declares a part of the stylesheet to allow this but it’ll will have to be done by whitespace (Which most people will probably not like, because of minification):
Sure, but I feel CSS should be readable in plain text format (it always has been). Why rely on an IDE if a different character achieves the same thing?
After experimenting today lots, I think I am still seeing the { syntax as the easiest to read.
I use zero formatting and highlighting in vim and as @leaverou said I’m a ‘extreme outlier on this’; but if I can cope most people can.
I would potentially suggest making it an @rule too (However this adds another type of @rule).
@MoOx reading the spec it seems to be doable in certain circumstances but perhaps I don’t understand. For example #id's would need to be turned into [id=...].
Taking this in a slightly different direction, here’s an alternate syntax proposal I’ve been mulling over and think I like.
The only reason we need anything special is because the grammar for declarations and selectors are ambiguous; specifically, a selector starting with a type selector and a pseudo-class looks just like a declaration, and you can’t tell which it is until you hit a curly or a semicolon.
If you can avoid that case, you’re golden. And the common case for nesting is to start the selector with the nesting selector. So:
As long as you’re starting the selector with the nesting selector, you can nest it directly inside of the parent rule. No Nesting Block or anything else needed. (Note: if you use a comma-separated list of selectors, all of them will have to start with the nesting selector, even though disambiguation has already technically been achieved by the first selector in the list. If you don’t have this restriction, it’s a refactoring hazard; re-arranging selectors can break code.)
If you want to use the nesting selector anywhere else inside of a selector (like .foo & to add extra styles only when it’s within a .foo ancestor), you have to add an @nest rule inside of the parent style rule, which then contains style rules with no restriction on & placement.
So in other words, these would be the two allowed syntaxes: