4 ms·
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
by 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 agoThanks 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.