WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WONTFIX
16020
A transition of width: auto to a fixed width computes auto as zero.
https://bugs.webkit.org/show_bug.cgi?id=16020
Summary
A transition of width: auto to a fixed width computes auto as zero.
Timothy Hatcher
Reported
2007-11-16 14:25:23 PST
A transition of width: auto to a fixed width computes auto as zero. See attached test case.
Attachments
Testcase
(271 bytes, text/html)
2007-11-16 14:25 PST
,
Timothy Hatcher
no flags
Details
Test case from related Radar, includes both % and auto widths.
(881 bytes, text/html)
2008-02-20 13:19 PST
,
James Craig
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Timothy Hatcher
Comment 1
2007-11-16 14:25:46 PST
Created
attachment 17321
[details]
Testcase
Dave Hyatt
Comment 2
2007-12-14 18:31:11 PST
This is tricky, since animation happens on RenderStyles, so a layout would actually be required in order to determine what the auto width value at the destination is going to be.
James Craig
Comment 3
2008-02-20 13:15:10 PST
Adding Radar I filed a while back. <
rdar://problem/5639997
> transition fails when animating between different size units (e.g. px and %)
James Craig
Comment 4
2008-02-20 13:19:01 PST
Created
attachment 19236
[details]
Test case from related Radar, includes both % and auto widths. Adding test case from related Radar, includes both % and auto widths.
mitz
Comment 5
2008-04-25 08:40:06 PDT
***
Bug 18726
has been marked as a duplicate of this bug. ***
Simon Fraser (smfr)
Comment 6
2009-01-09 17:44:21 PST
<
rdar://problem/5639997
>
Simon Fraser (smfr)
Comment 7
2009-02-27 10:29:14 PST
Comment from Dave Hyatt on the w3-style list: This is right. In WebKit, we transition on the computed value of a property (not the specified value or used value). Note that there have been requests to transition on the used value instead, the most obvious example being wanting to transition from, e.g., width:100% to width:50px. If you transition on the computed value, then it's impossible to run an animation from width:auto to width:50px or from width:50% to width:80px, etc. The problem with transitioning on the used value, though, is it can change when your style hasn't.... if you resize a window that contains a width:auto or width:100% block for example. Obviously you don't want to run a transition in that case. My own preference would be (for simplicity) to just stick with transitioning on the computed value and to just say "Tough" to people who want to animate width this way, but maybe others disagree. We continue to get bugs in WebKit from confused people trying to animate auto widths to fixed values (or percents to fixed values) and not understanding why it doesn't work.
Michael Kozakewich
Comment 8
2009-11-29 15:03:26 PST
***
Bug 31957
has been marked as a duplicate of this bug. ***
Maciej Stachowiak
Comment 9
2010-01-07 14:13:47 PST
How about we animate on the used value but only when the computed value changes?
Faruk Ates
Comment 10
2010-01-07 14:53:11 PST
Isn't the computed value internally kept as a pixel value no matter what the unit is? Wouldn't that mean that a change from width:80px to width:auto could do a non-transitioned lookup to see what pixel value "auto" currently computes to, and transition to that? I'm probably not understanding it, but it seems weird that every Javascript library in the world that does this has it figured out, but a hardware accelerated implementation can't?
Sidney San Martín
Comment 11
2010-01-20 08:58:29 PST
> My own preference would be (for simplicity) to just stick with transitioning on
the computed value and to just say "Tough" to people who want to animate width this way, but maybe others disagree. Many use cases for CSS transitions and animations include starting and ending at a computed value — showing and hiding content is a huge one. Also, treating computed values as zero is never going to be the right behavior. If this isn't going to be fixed, then trying to animate a computed property should kill the animation entirely.
Faruk Ates
Comment 12
2010-01-20 09:45:47 PST
I think not fixing this bug would be a grave mistake; this is the #1 use case for animation libraries used on the Web today, and thus, the #1 use case for the CSS Transitions implementation. And it is broken in CSS Transitions.
Simon Fraser (smfr)
Comment 13
2010-09-27 14:17:09 PDT
Dave Hyatt and I talked about how we might fix this. We'd have to do a layout at the start of the animation to compute the end state, but this might not work in some cases.
Simon Fraser (smfr)
Comment 14
2010-12-01 12:08:20 PST
***
Bug 35816
has been marked as a duplicate of this bug. ***
Simon Fraser (smfr)
Comment 15
2011-01-11 20:13:01 PST
***
Bug 52245
has been marked as a duplicate of this bug. ***
Simon Fraser (smfr)
Comment 16
2011-02-24 10:59:12 PST
***
Bug 55137
has been marked as a duplicate of this bug. ***
Sam Tsai
Comment 17
2011-04-27 11:15:48 PDT
Has there been any progress on this bug? Or are there alternate solutions that we could work towards?
Simon Fraser (smfr)
Comment 18
2011-07-25 12:16:03 PDT
***
Bug 65067
has been marked as a duplicate of this bug. ***
Nikita Vasilyev
Comment 19
2013-08-27 20:12:20 PDT
***
Bug 113871
has been marked as a duplicate of this bug. ***
Simon Fraser (smfr)
Comment 20
2016-05-02 18:00:48 PDT
The CSS WG has resolved that transitions don't run to/from auto values.
Joe Pea
Comment 21
2017-03-14 12:59:03 PDT
This resolution is very frustrating.
Joe Pea
Comment 22
2017-03-14 12:59:57 PDT
The web keeps disappointing. Are you browser devs really okay with that?
Simon Fraser (smfr)
Comment 23
2017-03-14 13:35:42 PDT
(In reply to
comment #22
)
> The web keeps disappointing. Are you browser devs really okay with that?
Please bring this up on www-style if you think it's important.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug