jquery: 3.1.x -> 3.2.x contains breaking change (`outerWidth` behavior)
Please pardon this lengthy issue report. If you think it should be split into multiple separate issues please let me know and I will attempt to do this, but I’m not sure how these observations relate.
This may be related to #3589 or the fixes for #3193 mentioned in the 3.2.0 release notes, but I’m not sure. (I don’t think it’s related to the 3.0 breaking change since it worked in previous 3.x versions.)
Problem 1: Firefox: .width()
& .outerWidth()
return %
values instead of px
values for inline elements
Tested on v45.8.0 (ESR) on Linux as well as 51.0.1 (32-bit) on Windows 10 (64-bit)
Duplicate of #3571 ~Problem 2: Chrome: .width()
returns 0
for inline elements~
Problem 3: .width()
/ .outerWidth()
gives different/wrong result on Chrome + Linux
This appears to be related to how padding is used in the calculation as well as to setting:
html {
box-sizing: border-box;
}
*, *:before, *:after {
box-sizing: inherit;
}
Background / Other Notes
This all started with a problem I had using Materialize. with the latest jQuery (3.2.1). The “tab indicator” suddenly started appearing too wide. You can see this here. After digging into this a bit I found that:
- It appears to affect Chrome on Linux (x86_64), not Firefox (ESR / 48.5.0) on Linux or common Windows browsers.
- It works fine with jQuery 3.1.x but not 3.2.x (assuming semver compliance this should not happen)
- Using
.get(0).getBoundingClientRect().width
instead of.outerWidth()
avoided the problem
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 19 (8 by maintainers)
Commits related to this issue
- Dimensions: Don't trust non-pixel computed width/height Fixes gh-3611 — committed to gibson042/jquery by gibson042 7 years ago
- Dimensions: Don't trust non-pixel computed width/height Fixes gh-3611 Closes gh-3741 — committed to jquery/jquery by gibson042 7 years ago
As of a49578499ec88c9fbca59ff0c80b23b798a55d99, everything is fixed except Problem 1.