Re: [css-background] Animating border-position

On 12/2/13, 1:52 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

>On Wed, Nov 27, 2013 at 10:47 AM, Alan Stearns <stearns@adobe.com> wrote:
>> Hey all,
>>
>> I brought up the issue of animating <position> last week, and Tab noted
>> that background-position is defined incorrectly [1]. Testing interop
>>shows
>> differences in how background-position animates as well [2, point 2].
>>
>> The problem is that by default, transitions occur over computed values.
>> The computed value for background-position include keywords, and there
>>is
>> no interpolation between keywords defined.
>>
>> This could be fixed by defining the computed value of
>>background-position
>> to be a list, with each item in the list containing two values of
>>length,
>> percentage or calc). This appears to be what Gecko does. But I’m not
>>sure
>> it’s useful to have a value of ‘right 10px’ be converted to ‘calc(100% -
>> 10px)’ in the computed value. And Fantasai raised the concern of future
>> extensions to <position> that might not be reducible to calc()
>>expressions.
>>
>> If we should leave the computed value definition as it is, then we’ll
>>need
>> to specify some keyword interpolation.
>>
>> An interim fix would add a definition that allows interpolation between
>> identical keywords - so that ‘left top 50px’ could interpolate with
>>‘left
>> top 100px’. This is what browsers appear to interopably implement. This
>> would not define animating from ‘left top 50px’ to ‘right top 100px’ -
>> which is something Blink does not do currently, but Gecko and IE11
>>appear
>> to handle.
>>
>> A full fix would define current <position> keyword interpolation for all
>> combinations.
>
>Investigating what FF actually does, it's rather clever.
>
>A "right <percentage>" is exactly equivalent to "left calc(100% -
><percentage>)", which is easy.
>
>A "right <length>" is, cleverly, exactly equivalent to "left calc(100%
>- <length>)", if you act as FF does for bg-position, and handle the
>percentage half and the pixel half of the calc() separately.
>
>I believe Chrome resolves the percentage into a <length>, which the
>spec actually requires, and makes this not actually possible to
>resolve.
>
>We've been over this before, I think, and haven't resolved on whether
>to change the spec for calc() or not, to allow <percentage>+<foo> as a
>top-level type accepted by some properties.

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?

Thanks,

Alan

Received on Monday, 16 December 2013 23:57:55 UTC