W3C home > Mailing lists > Public > public-css-archive@w3.org > September 2017

Re: [csswg-drafts] [css-variables] User Agent properties and variables

From: François REMY via GitHub <sysbot+gh@w3.org>
Date: Sun, 17 Sep 2017 17:24:08 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-330063919-1505669038-sysbot+gh@w3.org>
Replying to @tabatkins 

> > I have got a problem here, and my problem varies ;) More precisely, the values that we are discussing here are not going to be constants.
> Yeah, what eeeps said - they're constant over the page, as opposed to refs that can vary from element to element.
> > All in all, I have not seen any argument to convince me we should invest in adding a new function instead of a namespace for existing value references.
> A big difference is that these are usable in places other than properties and animations - you should be able to use these "constants" in MQs and such. (Again, because they're constant across the page, and so don't care about what context they're being used in.)  I'm loathe to say "var() is only allowed on elements normally, but you can use it wherever you want if you use this particular type of var name" - much better for everyone if it's a totally distinct name.

Ok, so I gave this another round of thoughts, and I agree that I can see the value in having a different function name to make it clear the places where the replacement will work are not the same. I still think this isn't needed, but I can see the value.

I really do not like the name `constant(...)` though. Really, there is no such thing as "constant at any given time". If you look at the definitions of "constant", you get either of these which both do not apply here (because the value of the variable can change over time):

> adj: remaining the same over a period of time
> noun: a situation or state of affairs that does not change

The other thing is that this is utterly verbose. If you have to use this multiple times in a calculation, having to type `constant()` is really annoying and space-filling, reducing gimpsability quite a lot.

I remember that when `var(...)` was introduced, we ruled out `$...` because it would conflict with css preprocessors, then also ruled out `$(...)` because Tab wanted to use it for things that would replace to the same thing globally. 

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.


GitHub Notification of comment by FremyCompany
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1693#issuecomment-330063919 using your GitHub account
Received on Sunday, 17 September 2017 17:24:01 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:18 UTC