Re: [css-background] Animating border-position

On Mon, Dec 16, 2013 at 3:56 PM, Alan Stearns <stearns@adobe.com> wrote:
> Another approach would be to change the computed value of
> background-position to ‘as specified’ and then sever the connection
> between specified value and the transition for this property. The
> background-position property could then define its transition as a simple
> list of length, percentage or calc where the values are defined as Gecko
> handles them today. Obfuscating the computed value for the purpose of
> handling the transition seems like a bad tradeoff to me.
>
> So I think there are two questions, which aren’t necessarily connected:
>
> (1) What should the computed value of background-position be?
>
> Is ‘as specified’ the most useful? Should the implied values be filled in?
> Or should it be reduced to a pair of calcs (even though future extensions
> might not be reducible in this way)?
>
> (2) How should we define the animation of background-position?
>
> Can the animation run over values that aren’t the computed values? Do we
> want to specify left-to-right transitions?

We don't want to try and decouple animations and computed values; it
won't help us any, it'll just result in another value stage (of which
we already have 6).  We just have to be careful about how we specify
the computed value of a <position> so that it can be animated well.

Now, we know that in the future we'll want to add logical directions.
We can't resolve those into physical directions at computed-value
time, because we want to limit computed values to only depend on the
style for the element and its parent, but the orientation might come
from any ancestor.

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.)

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.

Thoughts?

~TJ

Received on Tuesday, 17 December 2013 23:33:45 UTC