4 ms·

> 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/LES

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

culi 4y ago
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
- notpushkin 4y ago
  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.
  - culi 4y ago
    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
    - notpushkin 4y ago
      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.
      - culi 4y ago
        Right and now that we have (or will, soon enough) `:has`, I really don't think it's worth mucking up the potentially very simple and sweet nesting syntax to support something that's probably usually a bad practice anyways (though obviously I'm speaking from a place of little experience using this)
- wnevets 4y ago
  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.

culi 4y ago

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

notpushkin 4y ago
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.
- culi 4y ago
  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
  - notpushkin 4y ago
    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.
    - culi 4y ago
      Right and now that we have (or will, soon enough) `:has`, I really don't think it's worth mucking up the potentially very simple and sweet nesting syntax to support something that's probably usually a bad practice anyways (though obviously I'm speaking from a place of little experience using this)
wnevets 4y ago
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.