Re: [css3-transitions] transitioning to/from auto value

On 4/28/10 1:22 PM, Brad Kemper wrote:
>> On 4/28/10 11:07 AM, Brad Kemper wrote:
>>>>   Is the idea that all change processing needs to complete before sampling the "auto" height the transition should run to?
>>>
>>> Wel, yeah.
>>
>> That's not what your original mail said, though.
>
> I don't understand what I said that was contradictory.

You said to take the snapshot "as soon as a transition starts", which is 
when the computed value of the particular property changes.  But the 
ordering of that with changes to other computed values is undefined, is 
my point.

> Hmm. Maybe instead of just snapshotting the values, you also let other properties continue to change that snapshot of what "auto" means. Don't you have to do that sort of thing anyway for other values, such as percentages or ems/font-size? For instance:
>
> div#x {
>    transition: margin-right 1s;
>    margin-right : 0;
>    width: 100px;
> }
>
> Then I have:
>
> <div>
> 	<!-- The parent node is inside a 1000px padding box -->
> 	<div id="x">This is some text that is 150px wide</div>
> </div>
>
> and this script:
>
>   var divX = document.getElementById("x");
>   divX.style.marginRight = "50%";
>   divX.parentNode.style.width = "200px";

There are actually two things going on here:

1)  This is a transition from a length (0) to a percentage (50%).  Gecko 
does not support this at the moment, and the spec doesn't describe how 
it should happen, if at all.  The spec seems to assume that the type of 
value won't change during the transition.

2)  Had you used 0% instead of 0, the width of the parentNode doesn't 
affect the computed value, and transitions happen on computed values. 
So in this case there is one transition, running from 0% to 50%. 
Whenever the width change happens the then-current transitioning 
percentage is used to determine the new _used_ value, but the computed 
value is not affected so the transition just keeps on going.

> I would, because sequential lines of JavaScript within the same block are usually executed sequentially. Aren't they?

They are, and the _specified_ values change in the JS execution order. 
But nothing anywhere specifies how and when computed values should 
change; all browser guarantee is that they do change and that if you 
inspect them at any point they will be whatever they should be based on 
the specified values.  In practice, there's no hysteresis: no matter 
what order you set specified values of properties in, the end layout is 
the same.  It sounds to me like you're proposing breaking this 
author-expected behavior and introducing hysteresis, where the 
user-visible layout, for a while at least, will depend on the exact 
order of CSS property sets in a single chunk of run-to-completion JS. 
That would be a pretty serious violation of author expectations.

-Boris

Received on Wednesday, 28 April 2010 17:39:18 UTC