Skip to main content

Bug Tracker

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 timmywil comment:1

component: unfileddimensions
owner: → joneff
priority: undecidedlow
status: newpending

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

Changed November 18, 2011 03:54PM UTC by joneff <joneff@gmail.com> 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 timmywil comment:3

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.

Changed November 18, 2011 05:24PM UTC by joneff <joneff@gmail.com> 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 timmywil 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).