Bug Tracker

Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#10825 closed enhancement (wontfix)

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:



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


Note: in IE it takes more than this simple test case to reproduce

Change History (5)

comment:1 Changed 11 years ago by timmywil

Component: unfileddimensions
Owner: set to joneff
Priority: undecidedlow
Status: newpending

I think I'd rather have 64 than 65 there. Why do you think the ceil would be better?

comment:2 Changed 11 years ago by joneff <[email protected]…>

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)

comment:3 Changed 11 years ago by timmywil

Resolution: wontfix
Status: pendingclosed

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.


We cannot support retrieving width with gbcr because it would require far too much code.

comment:4 Changed 11 years ago by joneff <[email protected]…>

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.

comment:5 Changed 11 years ago by timmywil

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).

Note: See TracTickets for help on using tickets.