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

NEW
Assigned to

Status

()

Core
CSS Parsing and Computation
P4
normal
7 years ago
8 months ago

People

(Reporter: aza, Assigned: dbaron)

Tracking

(Blocks: 2 bugs, {dev-doc-needed})

Trunk
dev-doc-needed
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 -, status2.0 wanted)

Details

Attachments

(4 attachments)

(Reporter)

Description

7 years ago
CSS Transitions do not animate if auto-valued CSS properties are not explicitly set. See the attached movie for full bug description.
(Reporter)

Comment 1

7 years ago
Apparently the attachment was too big. Please see:

http://azarask.in/projects/tabcandy/css-animations.mov
(Reporter)

Comment 2

7 years ago
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));
  }    
});
Blocks: 537142
blocking2.0: --- → ?
(Reporter)

Updated

7 years ago
Assignee: nobody → dbaron
Keywords: dev-doc-complete
Keywords: dev-doc-complete → dev-doc-needed
blocking2.0: ? → -
status2.0: --- → wanted

Comment 3

7 years ago
I've got a reduced test case on http://csstransition.net (5th test)

Comment 4

7 years ago
Created attachment 524613 [details]
transition to 'auto' value 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

Updated

6 years ago
Duplicate of this bug: 664747

Comment 6

6 years ago
Other testcase: https://bugzilla.mozilla.org/attachment.cgi?id=539810

Comment 7

6 years ago
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"?
(Assignee)

Updated

6 years ago
OS: Mac OS X → All
Priority: -- → P4
Hardware: x86 → All

Comment 10

5 years ago
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.

Comment 12

4 years ago
Please fix. We are relying on Firefox to lead the way in supporting this very important functionality. Thank you for your time/consideration.
Created attachment 749587 [details]
Animated submenus

Updated

4 years ago
Attachment #749587 - Attachment description: Animatede → Animated submenus
Attachment #749587 - Attachment mime type: text/plain → text/html
Created attachment 750165 [details]
Transitioned submenus testcase

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.

Updated

4 years ago
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)
Duplicate of this bug: 896914

Comment 17

4 years ago
Is there a particular reason as to why browser vendors seemingly refuse to implement support for this?
(Assignee)

Comment 18

4 years ago
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'.)

Comment 19

4 years ago
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.

Comment 20

4 years ago
> http://pastebin.com/pPNvsqf1
Image here should be even bigger than box and with different proportions.
Comment hidden (abusive, advocacy, spam)
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.
(Assignee)

Comment 23

3 years ago
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"
Created attachment 8440770 [details]
simplified height testcase

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.
(Assignee)

Comment 27

a year ago
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.

Updated

8 months ago
You need to log in before you can comment on or make changes to this bug.