- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Tue, 19 Sep 2017 19:33:45 +0000
- To: public-css-archive@w3.org
> Should there be a standardized set of constant names with an expected meaning, or is that all up to the UA? I believe @grorg's pull request only defines the mechanism, but not any specific constant names. Yes, this isn't even a question. Without standardization, this is just vendor-specific, and thus worthless. (And thus should be protected behind whatever your vendor-specific-code mechanism is: prefixes or flags or what-have-you.) ------- > Why not follow the idea of currentColor? Because keywords need to be tracked and monitored for collisions; there are places where we accept arbitrary keywords (like `animation-name`) where we explicitly handle the few built-in keywords (and thus implicitly disallow you from using them as animation names/etc). Every time we add a new built-in keyword, we run the risk of breaking author code that is currently using it as a custom keyword. A function, on the other hand, can be handled globally without collision; we don't and will never allow user-defined functions with arbitrary names (they'll be `--` prefixed like other custom things), so there's no worry about breaking author-level code. ------- > I think this proposal matches that description: some value replacement that happens to be globally the same (but could be globally invalidated as a result of a value change). I would therefore propose we rename these variables to "globals" instead of "constants" and use $(...) to refer to them anywhere a css value is allowed. I'm fine with this; it does indeed match the use-case I was trying to reserve `$` for. It means some Syntax changes, tho. ^_^ -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1693#issuecomment-330649459 using your GitHub account
Received on Tuesday, 19 September 2017 19:34:07 UTC