Opened 12 years ago
Closed 9 years ago
#9628 closed bug (migrated)
width(), height(), etc. shouldn't round
Reported by: | john | Owned by: | mikesherov |
---|---|---|---|
Priority: | low | Milestone: | None |
Component: | css | Version: | 1.6.1 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
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 (19)
comment:1 Changed 12 years ago by
Component: | unfiled → css |
---|---|
Priority: | undecided → low |
comment:2 Changed 12 years ago by
Status: | new → open |
---|
comment:3 Changed 12 years ago by
Resolution: | → wontfix |
---|---|
Status: | open → closed |
comment:4 Changed 11 years ago by
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 11 years ago by
Boris, what do you suggest here, to just stop rounding if a fraction is returned?
comment:6 Changed 11 years ago by
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
comment:7 Changed 11 years ago by
Milestone: | 1.next → 1.9 |
---|---|
Owner: | set to mikesherov |
Status: | reopened → assigned |
comment:10 Changed 11 years ago by
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 11 years ago by
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 11 years ago by
From Boris: https://bugzilla.mozilla.org/show_bug.cgi?id=825607#c5
Just don't use offset*. Use getBoundingClientRect."
comment:13 Changed 11 years ago by
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:15 Changed 11 years ago by
Milestone: | 1.9 → None |
---|
comment:18 Changed 9 years ago by
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.
comment:19 Changed 9 years ago by
Resolution: | → migrated |
---|---|
Status: | assigned → closed |
Migrated to https://github.com/jquery/jquery/issues/1724
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.