4 ms·

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 readabl

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 differentiated from ".a { & .b { x: y; } }" (which would be equivalent to ".a .b { x: y; }"). Just ".a { .b { x: y; } }" looks ambiguous between the two, since it doesn't "look like" a descendant selector.

jjcm 4y ago
I don't think it needs to be required, but I'd 100% include that in any linter or style guide I had for code. For production code, I'd use it 100% of the time. For just quickly reorganizing some syntax around and copy/pasting things, I appreciate the shorthand version. I wouldn't use it in a codepen in most situations.
chrismorgan 4y ago
I very strongly agree. Mandatory & makes things much clearer, for a negligible cost. (And really, the curly braces, colon and semicolon are all mandatory (well, except the last semicolon of a ruleset), and alternative syntaxes with less punctuation like Sass’s have failed; the & is frankly more consistent than its absence.) For a more technical justification: with optional &, priority is given (by brevity) to the descendant combinator, but what of other combinators? Do they require & or not? It could reasonably go either way. I haven’t read recent proposals, but am very familiar with CSS grammar, and I’m genuinely unsure. parent { /* This might or might not work. */ > child { … } } parent { & > child { … } }
- jasonhansel 4y ago
  This is another good point, particularly because (IMHO) people tend to overuse the descendant combinator in places where they should really use the child combinator instead.
eyelidlessness 4y ago
I agree completely, and having followed this since it was a pipe dream, I’m actually sad that the machine parsing and unambiguous human readability convergence lasted so long to hold this up only to fall apart as it becomes a real possibility.
culi 4y ago
strongly agree as well. Option 3 with required "&"
franciscop 4y ago
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.
- bongobingo1 4y ago
  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?
  - franciscop 4y ago
    The problem is that "MyCSS framework" would not be a CSS framework, it'd be a full build system if it's incompatible, so that way no one would use the looser form. So if it's looser upstream, you can always tighten it more downstream in a fairly seamless and optional way, while the opposite is not really true.
mattwad 4y ago
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."
deleted 4y ago
[deleted]
Vinnl 4y ago
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; } }
- int_19h 4y ago
  They need to just bite the bullet and devise something other than & to clearly distinguish nesting.
  - Vinnl 4y ago
    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).
    - int_19h 4y ago
      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.
      - Vinnl 4y ago
        Ah, so you're calling on people to vote for option 4 or 5?
asd11 4y ago
Get WhatsApp live

jjcm 4y ago

I don't think it needs to be required, but I'd 100% include that in any linter or style guide I had for code. For production code, I'd use it 100% of the time. For just quickly reorganizing some syntax around and copy/pasting things, I appreciate the shorthand version. I wouldn't use it in a codepen in most situations.

chrismorgan 4y ago

I very strongly agree. Mandatory & makes things much clearer, for a negligible cost. (And really, the curly braces, colon and semicolon are all mandatory (well, except the last semicolon of a ruleset), and alternative syntaxes with less punctuation like Sass’s have failed; the & is frankly more consistent than its absence.) For a more technical justification: with optional &, priority is given (by brevity) to the descendant combinator, but what of other combinators? Do they require & or not? It could reasonably go either way. I haven’t read recent proposals, but am very familiar with CSS grammar, and I’m genuinely unsure. parent { /* This might or might not work. */ > child { … } } parent { & > child { … } }

jasonhansel 4y ago
This is another good point, particularly because (IMHO) people tend to overuse the descendant combinator in places where they should really use the child combinator instead.

eyelidlessness 4y ago

I agree completely, and having followed this since it was a pipe dream, I’m actually sad that the machine parsing and unambiguous human readability convergence lasted so long to hold this up only to fall apart as it becomes a real possibility.

culi 4y ago

strongly agree as well. Option 3 with required "&"

franciscop 4y ago

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.

bongobingo1 4y ago
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?
- franciscop 4y ago
  The problem is that "MyCSS framework" would not be a CSS framework, it'd be a full build system if it's incompatible, so that way no one would use the looser form. So if it's looser upstream, you can always tighten it more downstream in a fairly seamless and optional way, while the opposite is not really true.

mattwad 4y ago

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

deleted 4y ago

[deleted]

Vinnl 4y ago

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; } }

int_19h 4y ago
They need to just bite the bullet and devise something other than & to clearly distinguish nesting.
- Vinnl 4y ago
  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).
  - int_19h 4y ago
    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.
    - Vinnl 4y ago
      Ah, so you're calling on people to vote for option 4 or 5?

asd11 4y ago

Get WhatsApp live