- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 6 Jan 2014 14:59:15 -0800
- To: Alan Stearns <stearns@adobe.com>
- Cc: Bear Travis <betravis@adobe.com>, fantasai <fantasai.lists@inkedblade.net>, www-style list <www-style@w3.org>
On Mon, Jan 6, 2014 at 2:38 PM, Alan Stearns <stearns@adobe.com> wrote: > On 1/6/14, 1:58 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote: >>On Mon, Jan 6, 2014 at 1:36 PM, Bear Travis <betravis@adobe.com> wrote: >>> How should the values from getComputedStyle serialize? It worries me a >>> little to think that animations and getComputedStyle would use different >>> values. >> >>Computed values have nothing to do with serialization. Serializing >>just takes a value (which can be at *any* value stage) and returns a >>string holding a declared value which will have the same result. >> >>> If we were to serialize the above value, would it serialize as calcs all >>> the time? >>> "top calc(50% + 0px) left calc(100% - 20px)" >>> Or only where both a length and a percentage exist? >>> "top 50% left calc(100% - 20px)" >> >>Currently undefined, but the obviously correct answer is to only use >>calc()s when necessary. *Any* value in CSS might be a calc(); that >>doesn't imply that they all have to serialize as calc()s. > > So let’s get it defined. I’ve defined <position> serialization in > <basic-shape>s, leaning on what’s defined for image(). I’d really like to > see the serialization of background-position defined so that I know it > isn’t going to change out from under my definition. Yeah, we should define it. Someone has to do some basic experimentation to figure out if browsers agree, and if there are any weird things, see if there's a compat impact to defining it more sanely. ~TJ
Received on Monday, 6 January 2014 23:00:07 UTC