Last Comment Bug 571344 - Support transitions to and from 'auto' values of left, top, width, height, etc.
: Support transitions to and from 'auto' values of left, top, width, height, etc.
Status: NEW
: dev-doc-needed
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
P4 normal with 40 votes (vote)
: ---
Assigned To: David Baron :dbaron: ⌚️UTC-8
: Jet Villegas (:jet)
: 664747 896914 (view as bug list)
Depends on:
Blocks: css-transitions 660791
  Show dependency treegraph
Reported: 2010-06-10 14:18 PDT by Aza Raskin [:aza]
Modified: 2016-12-15 01:43 PST (History)
45 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

transition to 'auto' value Test. (3.85 KB, text/html)
2011-04-08 06:10 PDT, gossi
no flags Details
Animated submenus (6.59 KB, text/html)
2013-05-14 17:32 PDT, Robert Utasi [:hunboy]
no flags Details
Transitioned submenus testcase (6.40 KB, text/html)
2013-05-15 16:45 PDT, Robert Utasi [:hunboy]
no flags Details
simplified height testcase (1.23 KB, text/html)
2014-06-16 09:31 PDT, Robert Utasi [:hunboy]
no flags Details

Description User image Aza Raskin [:aza] 2010-06-10 14:18:13 PDT
CSS Transitions do not animate if auto-valued CSS properties are not explicitly set. See the attached movie for full bug description.
Comment 1 User image Aza Raskin [:aza] 2010-06-10 14:19:09 PDT
Apparently the attachment was too big. Please see:
Comment 2 User image Aza Raskin [:aza] 2010-06-10 14:20:58 PDT
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. 
  var cStyle = window.getComputedStyle(this, null);      
  for(var prop in css){
    $(this).css(prop, cStyle.getPropertyValue(prop));
Comment 3 User image Louis-Rémi BABE 2011-02-17 05:57:33 PST
I've got a reduced test case on (5th test)
Comment 4 User image gossi 2011-04-08 06:10:19 PDT
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.
Comment 5 User image Ben Bucksch (:BenB) 2012-01-11 12:44:39 PST
*** Bug 664747 has been marked as a duplicate of this bug. ***
Comment 6 User image Ben Bucksch (:BenB) 2012-01-11 12:45:37 PST
Other testcase:
Comment 7 User image Ben Bucksch (:BenB) 2012-01-11 12:48:25 PST
This bug makes CSS transitions fairly useless.
Simple usecase: Firefox notification bar should slide in. (It's currently implemented using JS there! :-( )
Comment 8 User image Burak Yiğit Kaya [:BYK] 2012-03-13 16:38:57 PDT
Another test case based on Zepto library:
Comment 9 User image Burak Yiğit Kaya [:BYK] 2012-03-13 16:40:31 PDT
This seems to be affecting all platforms, why is it marked as "Mac OS"?
Comment 10 User image MK 2012-07-26 19:50:14 PDT
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.
Comment 11 User image Boris Zbarsky [:bz] (still a bit busy) 2012-07-26 19:53:52 PDT
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 User image Dragon 2013-05-13 11:51:49 PDT
Please fix. We are relying on Firefox to lead the way in supporting this very important functionality. Thank you for your time/consideration.
Comment 13 User image Robert Utasi [:hunboy] 2013-05-14 17:32:26 PDT
Created attachment 749587 [details]
Animated submenus
Comment 14 User image Robert Utasi [:hunboy] 2013-05-15 16:45:26 PDT
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.
Comment 15 User image Robert Utasi [:hunboy] 2013-05-17 13:56:21 PDT

"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)
Comment 16 User image Boris Zbarsky [:bz] (still a bit busy) 2013-07-23 08:27:19 PDT
*** Bug 896914 has been marked as a duplicate of this bug. ***
Comment 17 User image Nils Kaspersson 2014-02-18 02:43:03 PST
Is there a particular reason as to why browser vendors seemingly refuse to implement support for this?
Comment 18 User image David Baron :dbaron: ⌚️UTC-8 2014-02-18 09:27:57 PST
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 User image zoonman 2014-03-19 12:32:31 PDT
Good example to test it

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 User image zoonman 2014-03-19 12:33:55 PDT
Image here should be even bigger than box and with different proportions.
Comment 21 User image yair even or 2014-06-11 03:42:28 PDT Comment hidden (abusive, advocacy, spam)
Comment 22 User image Robert Utasi [:hunboy] 2014-06-16 07:11:11 PDT

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.
Comment 23 User image David Baron :dbaron: ⌚️UTC-8 2014-06-16 07:41:00 PDT
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.
Comment 24 User image Robert Utasi [:hunboy] 2014-06-16 08:36:30 PDT

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"
Comment 25 User image Robert Utasi [:hunboy] 2014-06-16 09:31:58 PDT
Created attachment 8440770 [details]
simplified height testcase


here is a most reduced testcase for height auto issue
Comment 26 User image Ben Bucksch (:BenB) 2016-07-13 14:38:00 PDT
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.
Comment 27 User image David Baron :dbaron: ⌚️UTC-8 2016-07-13 15:06:16 PDT
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.

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