- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 17 Dec 2013 17:43:00 -0800
- To: fantasai <fantasai.lists@inkedblade.net>
- Cc: www-style list <www-style@w3.org>
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: >> However, as established by FF, we can at least convert values on >> opposite sides of the same axis into each other, if we establish that >> <percentage> can be preserved as a top-level type in a calc() in some >> cases, which we should do. (I'm fiddling with V&U right now to allow >> it. It's tricky to spec.) > > I'm confused as to why you think V&U needs changes. Because right now calc() specifies that a <percentage> resolves into a <length> (or whatever), but for <position> to work right, we need to preserve its percentage-ness. >> 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)]. >> >> You can only transition between two <position>s if the directions they >> contain are compatible - all physical, all logical, etc. Just match >> up the directions and transition the values, with missing directions >> on either side assumed to have an offset of 50%. >> >> That should handle things as we expand in the future. If we decide >> that it's okay to rely on orientation here, we can just convert the >> logical directions into a canonical physical direction at >> computed-value time. > > 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. Yeah, definitely. ~TJ
Received on Wednesday, 18 December 2013 01:43:48 UTC