Side navigation
#10825 closed enhancement (wontfix)
Opened November 18, 2011 12:32PM UTC
Closed November 18, 2011 04:43PM UTC
Last modified November 18, 2011 05:39PM UTC
Incorect width in FireFox / IE9 on Win7
Reported by: | joneff | Owned by: | joneff |
---|---|---|---|
Priority: | low | Milestone: | None |
Component: | dimensions | Version: | 1.7 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
Description
For some time now, both IE9 and FF have implemented sub pixel precision when it comes to dimensions. The jQ width methods however return the int of the value (not sure floor or round), instead of a float.
A workable solution would be to return the ceil as well.
Test case
http://jsfiddle.net/joneff/bD2Ef/
Note: in IE it takes more than this simple test case to reproduce
Attachments (0)
Change History (5)
Changed November 18, 2011 03:17PM UTC by comment:1
component: | unfiled → dimensions |
---|---|
owner: | → joneff |
priority: | undecided → low |
status: | new → pending |
Changed November 18, 2011 03:54PM UTC by comment:2
If you want to make a scrolling tab (UL with LI's), per say, you need to know the combined width of the items. It will, in the best case scenario, differ with at least a fraction of the pixel. Depending on your implementation, it might lower the last line, as it will not fit.
Why would I prefer ceil? For the aforementioned reason -- I think i'd better have a couple of pixels loose, than to have the last line.
The real questions are:
1) will all browsers implement sub pixel precision for dimensions
2) will widths continue to be int (apart from the bounding box method)
Changed November 18, 2011 04:43PM UTC by comment:3
resolution: | → wontfix |
---|---|
status: | pending → closed |
Actually, this may be invalid. We don't use getBoundingClientRect in .width(). We use elem.offsetWidth, which is an int in FF. So, we actually never round anything.
http://jsfiddle.net/timmywil/bD2Ef/3/
We cannot support retrieving width with gbcr because it would require far too much code.
Changed November 18, 2011 05:24PM UTC by comment:4
I am not really sure that this is entirely invalid.
I did some more test, that you can see here http://jsfiddle.net/joneff/GEdG8/. The tests are basically testing what browser report back via jQ and DOM for fraction dimensions.
A couple of findings:
1) browsers that don't support SPP (sub pixel precision) always yield the int part (floor)
2) hence .css() and getComputedstyles return the same values
3) in browsers that support SBP, width returns a round
4) hence .css() and getComputedStyles return different values
ref: http://api.jquery.com/css/
The .css() method ... to get a style property ... the getComputedStyle() method in standards-based browsers ...
(ellipsis mine)
So ultimately, even if my reasoning is not enough for improvement in the width methods / css method, you could consider it a bug report for the css method.
Changed November 18, 2011 05:39PM UTC by comment:5
CSS should return computed styles, but if subpixel precision is not supported across browsers, we need to normalize it so we never return subpixel values. It may not always be the same as getComputedStyle, but it should be the same across browsers (keeping in mind that different browsers have different default stylesheets so different values does not always mean there is a problem with .css).
I think I'd rather have 64 than 65 there. Why do you think the ceil would be better?