width(), height(), etc. shouldn't round

[john]

Right now we're rounding off the answers from width(), height(), etc. to the nearest pixel - this makes it hard to do good positioning of elements (especially for animations). For example if you have 3 items that are width 33% inside of a 100px element we're returning 33px for each element. Theoretically an animation method might be able to return a more interesting result if they know that there are extra fractional-numbers getting rounded off.

I got a report on this directly from Mozilla but I agree with them that this particular change makes it hard to get to good numbers.

See also: #3239.

[Rick Waldron]

For normalization purposes, jQuery core will maintain round pixel value returns, however you can easily write a cssHook to return the width/height in any value format that you prefer.

[bzbarsky]

Just to be clear, this bug makes width() completely useless for layout calculations in UAs that do subpixel layout: you compute some widths that look like they should fit in a container, but in fact they don't.

People are running into this all the time in UAs that in fact do subpixel layout (e.g. not WebKit).

[mikesherov]

Boris, what do you suggest here, to just stop rounding if a fraction is returned?

[dmethvin]

#12870 is a duplicate of this ticket.

[mikesherov]

#12373 is a duplicate of this ticket.

[mikesherov]

bzbarsky, if we could get FF to return floats for offsetWIdth and offsetHeight, that would solve this is. In fact, jQuery doesn't use the getComputedStyle().height for calculations. It uses offsetHeight, then subtracts/adds padding, border, margin as necessary. Perhaps I can file a bug with you about it ;-)

[mikesherov]

bzbarsky, reported to FF here: ​https://bugzilla.mozilla.org/show_bug.cgi?id=825607

I might take a stab at ditching offsetWidth/offsetHeight for jQuery 2.0 once oldIE codepaths are gone, but this would be fixed automatically if offsetWidth/Height stopped rounding.

[mikesherov]

From Boris: ​https://bugzilla.mozilla.org/show_bug.cgi?id=825607#c5

Just don't use offset*. Use getBoundingClientRect."

[mikesherov]

SO, the good news is that for FF, Chrome, Safari, and Opera , getBoundingClientRect work great, reporting subpixel values when appropriate, and containing a "width" property:

​http://jsfiddle.net/7MMhB/4/

However, the bad news is, IE9 reports "2" (as opposed to 3 for offsetWidth), IE<9 reports a TextRectangle object with no width property. Sigh.

If we truly want to get all subpixely, either we now see if we can drop offsetWidth altogether, or we do a feature detect for subpixely getBoundingRectClient, and use that when we can.

[mikesherov]

Oh, and IE10 works right too.

[dmethvin]

#14039 is a duplicate of this ticket.

[dmethvin]

#14556 is a duplicate of this ticket.

[dmethvin]

Ref: ​https://codereview.chromium.org/340903002/

Still, jQuery may be in a better position to do this, since the site gets to choose whether it wants to upgrade to a newer jQuery. It's a question of whether there are a lot of popular plugins that would break with fractional widths and heights.

[m_gol]

Migrated to ​https://github.com/jquery/jquery/issues/1724