- From: Sebastian Zartner <sebastianzartner@gmail.com>
- Date: Fri, 5 Jun 2015 09:42:22 +0200
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Lea Verou <lea@verou.me>, "Marat Tanalin | tanalin.com" <mtanalin@yandex.ru>, Boris Zbarsky <bzbarsky@mit.edu>, www-style list <www-style@w3.org>
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. 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.) Also what seems technically difficult now may be solvable in the future (freely interpreted by Lea's reference to Clarke). 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". Sebastian
Received on Friday, 5 June 2015 07:43:11 UTC