Open Bug 571344 Opened 14 years ago Updated 3 months ago

Support transitions to and from 'auto' values of left, top, width, height, etc.

Categories

(Core :: CSS Parsing and Computation, defect)

defect

Tracking

()

Tracking Status
blocking2.0 --- -
status2.0 --- wanted

People

(Reporter: aza, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: dev-doc-needed)

Attachments

(4 files)

CSS Transitions do not animate if auto-valued CSS properties are not explicitly set. See the attached movie for full bug description.
Apparently the attachment was too big. Please see:

http://azarask.in/projects/tabcandy/css-animations.mov
As a final note: from a content JS-side of things this can be worked around with something like:

// The latest versions of Firefox do not animate from a non-explicitly set
// css properties. So for each element to be animated, go through and
// explicitly define 'em. 
this.each(function(){
  var cStyle = window.getComputedStyle(this, null);      
  for(var prop in css){
    $(this).css(prop, cStyle.getPropertyValue(prop));
  }    
});
blocking2.0: --- → ?
Assignee: nobody → dbaron
I've got a reduced test case on http://csstransition.net (5th test)
I added an Example and TestCase, where a Transition to an auto value (here the height property) doesn't work.

Thanks in advance for fixing it.
Blocks: 660791
This bug makes CSS transitions fairly useless.
Simple usecase: Firefox notification bar should slide in. (It's currently implemented using JS there! :-( )
Another test case based on Zepto library: http://jsfiddle.net/vnyY5/
This seems to be affecting all platforms, why is it marked as "Mac OS"?
OS: Mac OS X → All
Priority: -- → P4
Hardware: x86 → All
This definitely affects all platforms, and needs fixing. It's been two years already, and as of version 14.0.1 of Firefox, this is still not fixed.
The current behavior is the one the spec requires.

Note that no browser actually supports this in any sane way.  Some browsers will treat "auto" as 0 and transition from that, but that's broken in most cases.
Please fix. We are relying on Firefox to lead the way in supporting this very important functionality. Thank you for your time/consideration.
Attachment #749587 - Attachment description: Animatede → Animated submenus
Attachment #749587 - Attachment mime type: text/plain → text/html
This testcase is for transition. The previous one was for animation. Both of them for height value. I havent found similar workaround for width value.
Attachment #750165 - Attachment mime type: text/plain → text/html
http://www.w3.org/TR/css3-animations/#values

"In addition to the property-specific values listed in their definitions, all properties defined in this specification also accept the ‘initial’ and ‘inherit’ keyword as their property value."

Although this is from the latest (2013-02-19) Animation draft, but same issue. My testcases here are based on this specification, and I used "height: initial".
(which one equals to "height: auto" value)
Is there a particular reason as to why browser vendors seemingly refuse to implement support for this?
Because it doesn't fit with the way CSS transitions work.  One could design and implement something that does this, but that would basically be redesigning transitions over again, and making them operate at a different level of the technology stack. (I think Tab Atkins was working on a proposal for something that would do this.)

(WebKit has/had a bug where it treats some 'auto' values as though they're '0', but that's different from doing this correctly, even though 'auto' values are sometimes equivalent to '0'.)
Good example to test it

http://pastebin.com/pPNvsqf1

I understand, it is hard to implement. But we can present it as element in two states.
Beginner - initial state. We can calculate it.
Second - with new applied values.
You can calculate pathway for points between two states of block, for example.
> http://pastebin.com/pPNvsqf1
Image here should be even bigger than box and with different proportions.
David,

probably we should separate this bug to parts.

At least for height and width.
The scrollHeight (contains padding) and scrollWidth (with white-space:nowrap) contains correct value so you should honor these properties based on these values. This helps lots to make horisontal and vertical menus without javascript hacks. This usage is more frequent, so covers the big part of palette of usage.

Note: max-height,max-width overflowing works as workaround (in that case if we know the max size of contents) but bad effect except linear and gets visible delay at reverse for different long content.
This bug should be addressed by supporting auto as a value in calc() expressions, which will in turn let transitions and animations express things like calc(auto * 0.25 + 400px * 0.75).  A bug on doing auto in calc() should perhaps be split into parts by the person implementing it, but this one shouldn't be.

I don't understand how comment 22 relates to this bug at all, but discussing that probably doesn't belong here; filing separate bugs on whatever comment 22 is about is probably appropriate.
David,

let me figure out with a *height* sample:

when "auto" equals to scrollHeight-padding then calc() looks like this:

calc((scrollHeight-padding) * 0.75 + 400px * 0.25)

if scrollheight-padding (the auto value of height) I say 1126px:

calc(1126px * x + 400px * (1-x)) ; x goes 0 to 1.

so it animates height from 400px (x=0) to 1126px (x=1);

What I say, if it is problematic for top,left etc while the auto value is zero (at position:relative/absolute), this bug is too universal, so we can separate those cases where it is possible to implement easily where the walue is known for "auto"
David,

here is a most reduced testcase for height auto issue
Dear layout engine team, could you please give this bug some love?
This is making CSS transitions useless in 90% of the cases where we want to use them.
Our current behavior matches what the spec requires; this feature should be developed at the spec level first, so the appropriate place to raise issues is the CSS Working Group, not here.

Comments on https://github.com/w3c/csswg-drafts/issues/626#issuecomment-267075654 are showing clearly that this affects many web developers and needs addressing. The status quo simply makes no sense for web developers, and it causes them serious problems.

Priority: P4 → --
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 43 votes and 53 CCs.
:emilio, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(emilio)
Flags: needinfo?(emilio)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: