Ticket #9628 (assigned bug)
width(), height(), etc. shouldn't round
| Reported by: | john | Owned by: | mikesherov |
|---|---|---|---|
| Priority: | low | Milestone: | None |
| Component: | css | Version: | 1.6.1 |
| Keywords: | Cc: | ||
| Blocking: | Blocked by: |
Description
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.
Change History
comment:1 Changed 2 years ago by john
- Priority changed from undecided to low
- Component changed from unfiled to css
comment:3 Changed 23 months ago by rwaldron
- Status changed from open to closed
- Resolution set to wontfix
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.
comment:4 Changed 6 months ago by 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).
comment:5 Changed 6 months ago by mikesherov
Boris, what do you suggest here, to just stop rounding if a fraction is returned?
comment:6 Changed 6 months ago by mikesherov
- Status changed from closed to reopened
- Resolution wontfix deleted
comment:7 Changed 6 months ago by mikesherov
- Owner set to mikesherov
- Status changed from reopened to assigned
- Milestone changed from 1.next to 1.9
comment:10 Changed 5 months ago by 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 ;-)
comment:11 Changed 5 months ago by 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.
comment:12 Changed 5 months ago by mikesherov
From Boris: https://bugzilla.mozilla.org/show_bug.cgi?id=825607#c5
Just don't use offset*. Use getBoundingClientRect."
comment:13 Changed 5 months ago by 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:
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.
comment:14 Changed 5 months ago by mikesherov
Oh, and IE10 works right too.
Please follow the bug reporting guidlines and use jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.
