- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 6 Jan 2014 14:57:26 -0800
- To: Bear Travis <betravis@adobe.com>
- Cc: fantasai <fantasai.lists@inkedblade.net>, www-style list <www-style@w3.org>
On Mon, Jan 6, 2014 at 2:45 PM, Bear Travis <betravis@adobe.com> wrote: >>This makes sense to me, we just have to be careful to specify how >><position> is serialized in getComputedStyle -- that it's not the >>computed value as described above. I don't want background-position >>to serialize differently from object-position, for example, just >>because object-position isn't in the list of 2.1 exceptions. > > I was unclear as to whether this meant that getComputedStyle would use a > different computed value, or that the serialization might take a value of > [(top, 50%), (left, 100% - 20px)] > And convert it to the string > "top 50% right 20px" or some other simpler form. It sounds like the latter > is the case. Nope, I was just saying that the computed value, which is an abstract value not directly accessible by the user, has that data structure. If you ask for the serialization of a computed value, such as the result of gCS(), you'll get a string of CSS syntax which produces the same result. > If these offsets are all calcs, should serialization simplify them where > possible, or should they not? Or am I fixating on a direct mapping between > the computed value and the equivalent CSS? You're fixating on a direct mapping between the value and the serialization. Most cases are simple enough that you can pretend the serialization and the value are the same thing, but not all. Note that the offsets are *not* calcs, because calc() is a bit of CSS syntax. They're just a length/percentage pair, which happens to be written with the calc() function when you serialize it. ~TJ
Received on Monday, 6 January 2014 22:58:13 UTC