Bug Tracker

Opened 8 years ago

Closed 8 years ago

Last modified 8 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:

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

Change History (5)

comment:1 Changed 8 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 8 years ago by joneff <joneff@…>

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

http://jsfiddle.net/timmywil/bD2Ef/3/

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

comment:4 Changed 8 years ago by joneff <joneff@…>

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