#10639 closed bug (fixed)
outerWidth(true) and css('margin') returning % instead of px in Webkit
Reported by: | Sprenger | Owned by: | mikesherov |
---|---|---|---|
Priority: | high | Milestone: | 1.7.2 |
Component: | css | Version: | 1.6.4 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description (last modified by )
If you have a relative margin (defined in %), jQuery(element).css('margin-right') will normally return the margin value in pixels not in percentage. In Webkit, this is not the case.
The method jQuery(element).outerWidth returns in IOS5 the addition of width (pixel) and margin (percentage) which mixes two different measures.
Test file: http://www.chateau-web.ch/demo/ios5-jquery-2.html
Tested with 1.6.4 and v1.7 (git) and 1.5. (same values for all versions)
Change History (16)
comment:1 Changed 12 years ago by
Component: | unfiled → css |
---|---|
Description: | modified (diff) |
Milestone: | None → 1.next |
Priority: | undecided → high |
Status: | new → open |
Summary: | outerWidth(true) and css('margin') returning % instead of px on iOS5 → outerWidth(true) and css('margin') returning % instead of px in Webkit |
comment:2 Changed 12 years ago by
chrome and FF are fundamentally different in how they report computed values. :-\
comment:3 Changed 12 years ago by
Unfortunately, it looks like a "wait for webkit to fix this" situation. The hack in the provided fiddle assumes that the parent is a pixel width element. In order to correctly work around the chrome bug, we would have to perform a russian doll approach, continuing to go up the tree correcting and coenverting all the way up the DOM, possibly until we're measuring the document's width/height until we get a sane value. I'm not sure jQuery wants to support that, but that's just my two cents.
Here are some resources related to this bug.
- Currently open bug in webkit regarding using "computed values" instead of "used value": https://bugs.webkit.org/show_bug.cgi?id=29084
- used value article from MDN: https://developer.mozilla.org/en/CSS/used_value
- YUI bug report for the same thing that is essentially a tumbleweed: http://yuilibrary.com/projects/yui3/ticket/2529799
comment:4 Changed 12 years ago by
I advocated for the bug on the chrome bugzilla: https://bugs.webkit.org/show_bug.cgi?id=29084
Anyone else feel like pitching in an opinion?
comment:5 Changed 12 years ago by
Gaining some traction to be fixed in webkit: https://bugs.webkit.org/show_bug.cgi?id=29084
comment:7 Changed 12 years ago by
https://github.com/jquery/jquery/pull/616 Still some potential perf issues to work out.
comment:8 Changed 12 years ago by
By the way, as an aside, open this fiddle in IE9,FF,0< or Webkit, they all report different values. getComputedStyle() and margins aren't friends: http://jsfiddle.net/u4F8m/13/
comment:9 Changed 12 years ago by
I've updated the PR, still pretty slow when this situation is encountered, but fast otherwise: https://github.com/jquery/jquery/pull/616
comment:11 Changed 12 years ago by
Milestone: | 1.next → 1.7.2 |
---|---|
Owner: | set to mikesherov |
Status: | open → assigned |
comment:12 Changed 12 years ago by
Just an update, this is going to be fixed in chrome itself, but this hack may still be necessary for older safari. https://twitter.com/#!/jarrednicholls/status/142049583915204608 https://bugs.webkit.org/show_bug.cgi?id=73334
comment:13 Changed 12 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Fix #10639. Make percent-specified margins return px values in WebKit.
Changeset: 7f6a991313380b74d5fb18782fb6b99fd6c4a22d
comment:14 Changed 12 years ago by
I've left a comment on the commit on GitHub because I'm not allowed to comment here. Fixing percentages in WebKit could be more robust.
comment:15 Changed 11 years ago by
Strangely, if an element has css 'min-width' value and a css margin value that is a %, in Safari (Version 5.1.7 (7534.57.2)), the returned value for $(element) is the 'min-width' value!
comment:16 Changed 11 years ago by
ntnwrd@…, please submit a new bug for that as its a different bug, please.
Confirmed. Probably related to the effects percentage issue.
Test case ported to jsfiddle: http://jsfiddle.net/timmywil/u4F8m/