Re: [css-transitions][css-background] Animating border-position

On 3/12/2013 8:52 AM, Tab Atkins Jr. 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].

When was this test performed and what was really tested?

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

And we should not define them until it's finalize if 'start' and 'end' 
keywords values can be used. Microsoft seems to want to resolve or work 
out serialization.

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

I suspect the reason for that is that keywords are not reordered in this 
instance. See the note for §3.6 in CSS3 backgrounds and borders.

   | Note that a pair of keywords can be reordered while
   | a combination of keyword and length or percentage cannot.
   | So ‘center left’ is valid while ‘50% left’ is not.

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

Actually it's magical (see far below with animation demo).

> A "right <percentage>" is exactly equivalent to "left calc(100% -
> <percentage>)", which is easy.

I would suspect this to be correct in theory. If position-y is not 
given, then we have FF behaviour vs IE11 and Chrome behaviour (when I 
last tested calc() a few months ago, neither IE10 and Opera supported it).

Is FF showing this demo (#test1) correctly? I would say yes.

<!doctype html>
<style type="text/css">
div {
   width: 200px; height: 200px; border: 10px solid silver; background: 
url(http://css-class.com/test/css/images/red-100px-100px.jpg) no-repeat;
}
#test1 { background-position: 100%; }
#test2 { background-position: left calc(100%-100%); }
</style>
<div id="test1"></div>
<div id="test2"></div>

Firefox seem to have interpret background-position differently for 
'#test2' where the value of position-y is ‘center’ which is what happens 
when only one value (axis) is given for background-position.

Test the following. Only the later is interoperable where calc(100%) is 
position-y.

background-position: left calc(100%-100%)

background-position: left calc(100%)


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

I would believe that 50px is a <length> and not a <percentage> or am I 
reading you wrong?

> 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.
>
> ~TJ

Something like right(10%) is less confusing for authors than say 'right 
calc(100%-10%)'.

Also Chrome does move from left to right when you use :hover in a 
transition. It is similar to transition from 'left:auto' to 'left:100%' 
in that it happens instantaneously.

The following demo will show the red background moving from left to 
right instantaneously on :hover and then transition from '100% 50%' to 
'100% 100%' When you un :hover, then the reverse happens where it 
transitions from '100% 100%' to '0% 100%', and the moves instantly from 
'0% 100%' to '0% 50%'

<!doctype html>
<style type="text/css">
div {
   width: 200px; height: 200px; border: 10px solid silver; background: 
url(http://css-class.com/test/css/images/red-100px-100px.jpg) no-repeat;
   background-position: left top 50px;
   transition: 2s linear;
}
div:hover { background-position: right top 100px; }
</style>
<div></div>


Now for the magical Firefox behaviour. It seems to also be what I 
expect. IE11 animates from 'top left' to 'bottom left' where Opera is 
always positioned at 'bottom right' which is strange.

<!doctype html>
<style type="text/css">
div {
   width: 200px; height: 200px; border: 10px solid silver; background: 
url(http://css-class.com/test/css/images/red-100px-100px.jpg) no-repeat;
   -webkit-animation: move 2s infinite linear;
   -ms-animation: move 2s infinite linear;
   -o-animation: move 2s infinite linear;
   animation: move 2s infinite linear;
}
@-webkit-keyframes move {
 100% { background-position: right top 100px; }
}
@-ms-keyframes move {
 100% { background-position: right top 100px; }
}
@-o-keyframes move {
 100% { background-position: right top 100px; }
}
@keyframes move {
 100% { background-position: right top 100px; }
}
</style>
<div></div>


Alan



-- 
Alan Gresley
http://css-3d.org/
http://css-class.com/

Received on Tuesday, 3 December 2013 02:35:02 UTC