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

On Fri, Jun 5, 2015 at 12:42 AM, Sebastian Zartner
<sebastianzartner@gmail.com> wrote:
> On 5 June 2015 at 03:21, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> 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:
>>>> 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.
>>
>>>> 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.
>
> Memory issues will relativize with the time.

Invoking Moore's Law to justify a feature becoming less terrible in
the future isn't really a great argument for doing that feature *now*.
^_^

And they likely won't, either.  Applications grow to fill the memory
available to them.  Adding an eff-ton more memory usage to every page
all of a sudden will never be something ignorable.

> Also, memory can be freed
> again as soon as it's recognized there is no var() reference to a
> normal property. (This of course requires recomputing once a var()
> reference is added later on.)

This won't happen.  It's a ton of memory churn and extra computation,
particularly if var()s appear and disappear.

> Also what seems technically difficult now may be solvable in the
> future (freely interpreted by Lea's reference to Clarke).

In the magical future where this is more doable, we can relitigate this. ^_^

> Anyway, I don't have an opinion on whether to allow var() to be used
> for normal properties or not. Just wanted to say "never say never".

"Never" can freely be interpreted as "never, given current evidence
and reasonable predictions, but subject to reinterpretation if facts
dramatically change".

~TJ

Received on Friday, 5 June 2015 21:24:18 UTC