- From: Bear Travis <betravis@adobe.com>
- Date: Mon, 6 Jan 2014 21:36:23 +0000
- To: Tab Atkins Jr. <jackalmage@gmail.com>, fantasai <fantasai.lists@inkedblade.net>
- CC: www-style list <www-style@w3.org>
Hi All, I had some quick follow-up questions/comments about serialization. On 12/17/13, 5:43 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote: >On Tue, Dec 17, 2013 at 4:21 PM, fantasai <fantasai.lists@inkedblade.net> >wrote: >> On 12/17/2013 03:32 PM, Tab Atkins Jr. wrote: >>> So, here's my proposal: >>> >>> The computed value of a <position> is a set of zero or more >>> (direction, offset) pairs, where each axis chooses one direction as >>> canonical and an offset is a sum of a percentage and a length. >>> Specified directions that are the non-canonical one are converted to >>> the canonical one. >>> >>> So, "top 50% right 20px" would result in a computed value of [(top, >>> 50%), (left, 100% - 20px)]. >>> >> >> 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. How should the values from getComputedStyle serialize? It worries me a little to think that animations and getComputedStyle would use different values. 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)" -Bear
Received on Monday, 6 January 2014 21:37:05 UTC