Bug Tracker

Modify

Ticket #9628 (assigned bug)

Opened 2 years ago

Last modified 3 months ago

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:2 Changed 2 years ago by addyosmani

  • Status changed from new to open

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:8 Changed 6 months ago by dmethvin

#12870 is a duplicate of this ticket.

comment:9 Changed 5 months ago by mikesherov

#12373 is a duplicate of this ticket.

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:

 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.

comment:14 Changed 5 months ago by mikesherov

Oh, and IE10 works right too.

comment:15 Changed 3 months ago by dmethvin

  • Milestone changed from 1.9 to None

Please follow the  bug reporting guidlines and use  jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.

View

Add a comment

Modify Ticket

Action
as assigned
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.