4 ms·

It's also possible to define custom author-defined features fully within standard CSS syntax, which can then be safely picked up and processed by tools (server

by err4nt 3y ago

It's also possible to define custom author-defined features fully within standard CSS syntax, which can then be safely picked up and processed by tools (server side or client-side) and handled without needing a custom language and its own custom syntax. It's a solution that's far, far bigger than the problem it solves.

cantSpellSober 3y ago
Eh they have some really well-done Sass functions, finding "enough contrast" for example: https://github.com/jgthms/bulma/blob/main/sass/utilities/functions.scss#L200-L214 https://github.com/jgthms/bulma/blob/main/sass/utilities/fun... The closest to that in CSS is color-contrast() which isn't in any browser yet. There's a lot CSS still can't do.
- moritzwarhier 3y ago
  I think the comment you are responding to is thinking about native ways to extend CSS without violating or extending the syntax rules. For example, @-rules. The actual interpolation/processing would still be outside of the browser. IIRC, the normative framework for this is pretty new, and I don't now the rules about function names. The pain with SASS et al is real though. Most frequent offenders in my experience: - the max() function - the division symbol occuring in values of native properties such as grid-column or aspect-ratio Both have been deprecated in newer versions, but it is impossible to automatically fix this unless you know that all of your (S)CSS was written before these features were introduced.
  - err4nt 3y ago
    As far as I know the rules were set in stone by 2013 or around there so while they haven't been widely taught or have tons of blog posts written about them they are safe and futureproof in that way. From what I understand around the time of the design of the syntax for CSS custom properties (which have '--' a double-dash prefixed to the start of the term) they decided that all author-defined parts of CSS syntax will always begin with a double dash '--', which is like a vendor prefix (e.g. '-webkit-' or '-moz-' etc) but with no vendor. So if a function in CSS is func(), then a custom author-defined function will always be --func() and it should be parsed and safely ignored by browsers or things that don't understand it, but still present in your CSS for tools to read and operate on so you can define custom features and use them within standard CSS no matter how or where you are providing the support (you could process some things in advance like a preprocessor, or it might be a feature that only makes sense to support client-side in a browser or at the time the CSS is being evaluated).
    - moritzwarhier 3y ago
      Thanks for the info! That was the rule I was hoping exists but couldn't bother to look up. Totally makes sense and fits well with CSS custom properties. While naming rules as syntax might seem smelly when it exceeds banning keywords as identifiers, I find this to be a sensible and well-thought-out rule, similar to the Custom Element dash-tag-name rule (notwithstanding other issues with the Web Component standard) It's KISS and does it's best to make a good tradeoff regarding forwards-compatibility.

by err4nt 3y ago

cantSpellSober 3y ago

Eh they have some really well-done Sass functions, finding "enough contrast" for example: https://github.com/jgthms/bulma/blob/main/sass/utilities/functions.scss#L200-L214 https://github.com/jgthms/bulma/blob/main/sass/utilities/fun... The closest to that in CSS is color-contrast() which isn't in any browser yet. There's a lot CSS still can't do.

moritzwarhier 3y ago
I think the comment you are responding to is thinking about native ways to extend CSS without violating or extending the syntax rules. For example, @-rules. The actual interpolation/processing would still be outside of the browser. IIRC, the normative framework for this is pretty new, and I don't now the rules about function names. The pain with SASS et al is real though. Most frequent offenders in my experience: - the max() function - the division symbol occuring in values of native properties such as grid-column or aspect-ratio Both have been deprecated in newer versions, but it is impossible to automatically fix this unless you know that all of your (S)CSS was written before these features were introduced.
- err4nt 3y ago
  As far as I know the rules were set in stone by 2013 or around there so while they haven't been widely taught or have tons of blog posts written about them they are safe and futureproof in that way. From what I understand around the time of the design of the syntax for CSS custom properties (which have '--' a double-dash prefixed to the start of the term) they decided that all author-defined parts of CSS syntax will always begin with a double dash '--', which is like a vendor prefix (e.g. '-webkit-' or '-moz-' etc) but with no vendor. So if a function in CSS is func(), then a custom author-defined function will always be --func() and it should be parsed and safely ignored by browsers or things that don't understand it, but still present in your CSS for tools to read and operate on so you can define custom features and use them within standard CSS no matter how or where you are providing the support (you could process some things in advance like a preprocessor, or it might be a feature that only makes sense to support client-side in a browser or at the time the CSS is being evaluated).
  - moritzwarhier 3y ago
    Thanks for the info! That was the rule I was hoping exists but couldn't bother to look up. Totally makes sense and fits well with CSS custom properties. While naming rules as syntax might seem smelly when it exceeds banning keywords as identifiers, I find this to be a sensible and well-thought-out rule, similar to the Custom Element dash-tag-name rule (notwithstanding other issues with the Web Component standard) It's KISS and does it's best to make a good tradeoff regarding forwards-compatibility.