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

On Thu, Jun 4, 2015 at 5:04 PM, Lea Verou <lea@verou.me> wrote:
>> 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.

That wasn't a promise, but a fact.  I'm telling you right now that the
downsides to this *far* outweigh the upsides, such that it will never
actually happen.  It doesn't matter what justifications there are,
doing this is extremely difficult technically, would result in major
memory bloat for *all* pages, not just those who use this feature, and
would cripple our ability to develop CSS into the future.  It's just
not going to happen.

>> 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?

It doesn't.  If we make this change, and pages start to use var() to
link normal properties together, *those* pages will be broken in
unpredictable ways as we extend CSS.

>> 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.

No, it doesn't solve any of the hard issues.

>> 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.”

"Non-minor" is a significant understatement.  It would mean
*massively* bloating memory usage of pages - *all* pages, even those
that don't use this feature.  This is not in any way Blink-specific;
Xidorn brought it up in the context of Firefox.

~TJ

Received on Friday, 5 June 2015 01:22:20 UTC