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)
Core
CSS Parsing and Computation
Tracking
()
NEW
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.
Reporter | ||
Comment 1•14 years ago
|
||
Apparently the attachment was too big. Please see: http://azarask.in/projects/tabcandy/css-animations.mov
Reporter | ||
Comment 2•14 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: css-transitions
blocking2.0: --- → ?
Reporter | ||
Updated•14 years ago
|
Assignee: nobody → dbaron
Updated•14 years ago
|
Keywords: dev-doc-complete
Updated•14 years ago
|
Keywords: dev-doc-complete → dev-doc-needed
Comment 3•13 years ago
|
||
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.
Comment 6•12 years ago
|
||
Other testcase: https://bugzilla.mozilla.org/attachment.cgi?id=539810
Comment 7•12 years ago
|
||
This bug makes CSS transitions fairly useless. Simple usecase: Firefox notification bar should slide in. (It's currently implemented using JS there! :-( )
Comment 8•12 years ago
|
||
Another test case based on Zepto library: http://jsfiddle.net/vnyY5/
Comment 9•12 years ago
|
||
This seems to be affecting all platforms, why is it marked as "Mac OS"?
OS: Mac OS X → All
Priority: -- → P4
Hardware: x86 → All
Comment 10•12 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.
Comment 11•12 years ago
|
||
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•11 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.
Comment 13•11 years ago
|
||
Updated•11 years ago
|
Attachment #749587 -
Attachment description: Animatede → Animated submenus
Attachment #749587 -
Attachment mime type: text/plain → text/html
Comment 14•11 years ago
|
||
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•11 years ago
|
Attachment #750165 -
Attachment mime type: text/plain → text/html
Comment 15•11 years ago
|
||
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)
Comment 17•10 years ago
|
||
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'.)
Comment 19•10 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•10 years ago
|
||
> http://pastebin.com/pPNvsqf1
Image here should be even bigger than box and with different proportions.
Comment hidden (abuse-reviewed, advocacy, spam) |
Comment 22•10 years ago
|
||
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.
Comment 24•10 years ago
|
||
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"
Comment 25•10 years ago
|
||
David, here is a most reduced testcase for height auto issue
Comment 26•8 years ago
|
||
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.
Updated•7 years ago
|
Assignee: dbaron → nobody
Comment 28•3 years ago
|
||
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 → --
Updated•2 years ago
|
Severity: normal → S3
Comment 29•2 years ago
|
||
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)
Updated•2 years ago
|
Flags: needinfo?(emilio)
Duplicate of this bug: 1167265
There's now an active proposal for this in the CSS Working Group that the group agreed to adopt into css-values-5.
You need to log in
before you can comment on or make changes to this bug.
Description
•