W3C home > Mailing lists > Public > www-style@w3.org > December 2013

Re: [css-background] Animating border-position

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 17 Dec 2013 16:21:50 -0800
Message-ID: <52B0EA9E.5040500@inkedblade.net>
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.

Received on Wednesday, 18 December 2013 00:22:21 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:17 UTC