- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 17 Dec 2013 16:21:50 -0800
- To: www-style@w3.org
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. > 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. ~fantasai
Received on Wednesday, 18 December 2013 00:22:21 UTC