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

Re: [css-background] Animating border-position

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 17 Dec 2013 17:43:00 -0800
Message-ID: <CAAWBYDCZaRAOH-S6FJd7J18grBBm4uytD+iD1MkEDdrfCiAN_A@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 18 December 2013 01:43:48 UTC