3 ms·

I don't think the CSSWG should care one bit about Sass's syntax. Just use if...else if that's what makes sense (and I think it does make sense). Sass is interpr

by joemi 5y ago

I don't think the CSSWG should care one bit about Sass's syntax. Just use if...else if that's what makes sense (and I think it does make sense). Sass is interpreted into CSS, so CSS is the authoritative language, and Sass is a derivative.

silvestrov 5y ago
Yes, sass should change now that css will support conditionals. sass stepped on css' toes by reusing the @xxx syntax from css instead of creating their own syntax.
- systemvoltage 5y ago
  Sass should just have been a python (or your fav lang) library. Express the entire CSS as objects and then finally compile it. There was no need for yet another DSL. DSLs seems like the easy way out but it puts a lot of burden for users to learn it. It is pretty compact and clean though. So there's that.
- munk-a 5y ago
  > sass stepped on css' toes by reusing the @xxx syntax from css instead of creating their own syntax. Yes and no - they're accepting that there may be future compatibility breaks (like this very case) but using some arbitrary other glyph as a marker is also dangerous. Whenever you're working on a second layer tool you're limited in how much future compatibility you can guarantee (and the limit is 0).
  - kazinator 5y ago
    A given piece of working SASS never has to have a compatibility issue, because it's processed through SASS and the SASS goes away. (Only some backward-incompatible upgrade to SASS can break the code.) The fact that CSS evolves to introduce constructs that look exactly like SASS doesn't in and of itself break anything from the point of view of the old code which doesn't use those new CSS constructs. SASS code is written in the SASS language, with CSS as a back-end; the only thing that can break a piece of existing SASS code (in terms of making it either fail to generate, or generate different CSS) is a backwards-incompatible upgrade to the SASS processor. For instance, someone has SASS code which relies on certain @-things to be passed through to CSS, but an upgrade to SASS claims some of them for itself. (A change in CSS could break the generated CSS code, which is a different issue.)
    - lmm 5y ago
      To the extent that SASS wishes to remain a superset of CSS, and/or allow expressing any possible output CSS, a change in CSS can break that aspect of SASS and force SASS to make an incompatible change if it wants to preserve those properties.
  - chrismorgan 5y ago
    It’s not just @-rules, but also other things like functions, where they’ve introduced their own that end up definitely incompatible with CSS and it’s just no end of pain as you try using now-ordinary CSS features and discover that a technical decision made fifteen or more years ago prevents you from doing so. (The deprecated LibSass is significantly CSS-incompatible; Dart Sass, I’m not sure: even a year ago it was still significantly incompatible, but they have definitely landed some important fixes since then so that it’s possible that their long-standing claim on https://sass-lang.com/ https://sass-lang.com/ that “Sass is completely compatible with all versions of CSS” is no longer a blatant lie.) I think most of the trouble is actually that Sass accepted the theoretical compatibility breaks on behalf of their users, who didn’t realise they were signing up for this, and end up discouraged when breakages happen and they have to resort to ever weirder and wackier workarounds that should work but somehow break things in some other part of their toolchain, et cetera ad desperationem. I think it would have been much better if every piece of Sass syntax had used been clearly denoted by the use of the $ symbol ($@ instead of @ for its at-rules, a $ prefix on its functions, &c.), except probably for nesting (though not bare mathematical expressions, I’d force them to be wrapped in $(…)—they’re the worst to find when trying to port away from Sass syntactically rather than compilationally). $ was and is not used by CSS and could probably be agreeably reserved for such tools, and even if not, the unquestionable superiority for tooling (that it makes identifying Sass rather than CSS parts of the stylesheet textually trivial rather than absolutely requiring a compiler that is unlikely to be designed for general tooling use) would even make switching from $ to something else (e.g. a -sass- prefix, which would also be a reasonable choice, though slightly more verbose) genuinely easy. But of course, that ship has long sailed, and I have no time machine.

by joemi 5y ago

silvestrov 5y ago

Yes, sass should change now that css will support conditionals. sass stepped on css' toes by reusing the @xxx syntax from css instead of creating their own syntax.

systemvoltage 5y ago
Sass should just have been a python (or your fav lang) library. Express the entire CSS as objects and then finally compile it. There was no need for yet another DSL. DSLs seems like the easy way out but it puts a lot of burden for users to learn it. It is pretty compact and clean though. So there's that.
munk-a 5y ago
> sass stepped on css' toes by reusing the @xxx syntax from css instead of creating their own syntax. Yes and no - they're accepting that there may be future compatibility breaks (like this very case) but using some arbitrary other glyph as a marker is also dangerous. Whenever you're working on a second layer tool you're limited in how much future compatibility you can guarantee (and the limit is 0).
- kazinator 5y ago
  A given piece of working SASS never has to have a compatibility issue, because it's processed through SASS and the SASS goes away. (Only some backward-incompatible upgrade to SASS can break the code.) The fact that CSS evolves to introduce constructs that look exactly like SASS doesn't in and of itself break anything from the point of view of the old code which doesn't use those new CSS constructs. SASS code is written in the SASS language, with CSS as a back-end; the only thing that can break a piece of existing SASS code (in terms of making it either fail to generate, or generate different CSS) is a backwards-incompatible upgrade to the SASS processor. For instance, someone has SASS code which relies on certain @-things to be passed through to CSS, but an upgrade to SASS claims some of them for itself. (A change in CSS could break the generated CSS code, which is a different issue.)
  - lmm 5y ago
    To the extent that SASS wishes to remain a superset of CSS, and/or allow expressing any possible output CSS, a change in CSS can break that aspect of SASS and force SASS to make an incompatible change if it wants to preserve those properties.
- chrismorgan 5y ago
  It’s not just @-rules, but also other things like functions, where they’ve introduced their own that end up definitely incompatible with CSS and it’s just no end of pain as you try using now-ordinary CSS features and discover that a technical decision made fifteen or more years ago prevents you from doing so. (The deprecated LibSass is significantly CSS-incompatible; Dart Sass, I’m not sure: even a year ago it was still significantly incompatible, but they have definitely landed some important fixes since then so that it’s possible that their long-standing claim on https://sass-lang.com/ https://sass-lang.com/ that “Sass is completely compatible with all versions of CSS” is no longer a blatant lie.) I think most of the trouble is actually that Sass accepted the theoretical compatibility breaks on behalf of their users, who didn’t realise they were signing up for this, and end up discouraged when breakages happen and they have to resort to ever weirder and wackier workarounds that should work but somehow break things in some other part of their toolchain, et cetera ad desperationem. I think it would have been much better if every piece of Sass syntax had used been clearly denoted by the use of the $ symbol ($@ instead of @ for its at-rules, a $ prefix on its functions, &c.), except probably for nesting (though not bare mathematical expressions, I’d force them to be wrapped in $(…)—they’re the worst to find when trying to port away from Sass syntactically rather than compilationally). $ was and is not used by CSS and could probably be agreeably reserved for such tools, and even if not, the unquestionable superiority for tooling (that it makes identifying Sass rather than CSS parts of the stylesheet textually trivial rather than absolutely requiring a compiler that is unlikely to be designed for general tooling use) would even make switching from $ to something else (e.g. a -sass- prefix, which would also be a reasonable choice, though slightly more verbose) genuinely easy. But of course, that ship has long sailed, and I have no time machine.