W3C home > Mailing lists > Public > www-style@w3.org > June 2015

Re: [css-variables] Why we can not use 'var()' function for normal property

From: Lea Verou <lea@verou.me>
Date: Thu, 4 Jun 2015 20:04:34 -0400
Cc: "Marat Tanalin | tanalin.com" <mtanalin@yandex.ru>, Boris Zbarsky <bzbarsky@mit.edu>, www-style list <www-style@w3.org>
Message-Id: <6251A079-C8E6-41AD-B551-0BD6B07D2458@verou.me>
To: "Tab Atkins Jr." <jackalmage@gmail.com>

> On Jun 2, 2015, at 16:34, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> If you want property A to have the same value as
> property B, set up a custom property and use it in both of them.

This is not possible in many cases (i.e. libraries that have to work in a host environment) and creates very tightly coupled code even when it is, which is an antipattern.

> You can't refer to the values of other properties.  Full stop.  It won't happen.  

> This is not something we will allow, ever.

Whoa. That’s an …interesting form of consensus.

> Every possible strategy involves breaking pages as we
> extend the language.


> There is no solution to this problem that doesn't break pages as we
> update the language and add new implicit dependencies between
> properties.

Not sure how it will break *existing* code that doesn’t use val() to refer to other properties. Care to elaborate?

> This is an unsolvable problem.

[insert obligatory reference to Clarke’s Three Laws… ;) ]

Also, reference to François’ solution, that could be a nice starting point.

> Yup, and reconstructing the value isn't feasible; our internal storage
> of the value often loses important information like ordering, or can't
> tell between specifying a default keyword or omitting it, etc.
> There's no way for us to tell which types of information loss are
> acceptable, and which will result in a secondary property using var()
> to break, because you no longer match the second property's grammar.
> (That is, two properties might have *similar* grammars for something,
> and the form the author put into the stylesheet works in both, but the
> form we reserialize to doesn't match the second property's grammar.)

This sounds an awful lot like “This is an unsolvable problem because it requires actual, non-minor changes to the Blink codebase.”

> On May 13, 2015, at 09:37, BangSeongbeom <bangseongbeom@hotmail.com> wrote:
> 
> 'var()' function is limited for custom property only.
> Custom properties and normal properties should be treated equally.
> Like this:
> ..foo {
>     --wall: 100px;
>     padding-bottom: 50px;
> }
> ..foo .bar {
>     margin-top: var(--wall);
>     padding-top: var(padding-bottom);
> }

This would not work, even if var() *could* refer to any property, since padding-bottom is not inherited. It would become the padding-bottom of .bar, which would be the initial value.

~Lea
Received on Friday, 5 June 2015 00:04:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:54 UTC