Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

`outerWidth()` doesn't work on IE when content width matches style=width specification when `box-sizing` set to `border-box`. #4102

rgavrilov opened this issue Jun 13, 2018 · 3 comments


Copy link

@rgavrilov rgavrilov commented Jun 13, 2018


.outerWidth() calculation on IE 11 (Version: 11.98.16299.0IS, Windows 10 64-bits) is different from Chrome and is wrong, I think.

In the attached test case I have a table with 3 header rows. First cell in each row has a different width (200px, 190px, 180px), top row overrides width of cells in the
When width specified in style attribute matches content width of the element - the value returned by .outerWidth() is different.

Running the test case on IE (in console) produces 200, 190, 200 while on Chrome the result is 200, 200, 200.

This is messes with my dataTables and fixedColumn.dataTables components that rely on .css('width') and hence .outerWidth().

The problem seems to be in getWidthOrHeight function (jQuery v3.3.1). Specifically this line (6368):

	// Check for style in case a browser which returns unreliable values
	// for getComputedStyle silently falls back to the reliable
	valueIsBorderBox = valueIsBorderBox &&
		( support.boxSizingReliable() || val ===[ dimension ] );

val is coming from window.getComputedStyle().width but['width'] is coming from style attribute (as I understand it). And when these two values are equal it leads jQuery to believe that val is a border box size already and doesn't add padding.

Changing the width of the second row cell to 191px or 189px results in outerWidth() of the problematic cell (th) to 200.

Link to test case

I expect all 3 values printed to codepen's console to be the same, but they differ on IE, even though all 3 TH cells (of the first column) are of the same width.

Copy link

@vmcruz vmcruz commented Jul 15, 2018

I tested this on IExplorer 11, Windows 8.1 x64 and confirmed this behavior.

@timmywil timmywil added this to the 3.4.0 milestone Sep 3, 2018
@timmywil timmywil added the Offset label Sep 3, 2018
Copy link

@timmywil timmywil commented Sep 3, 2018

Updated testcase to include cases for #4044 and #4043:

@timmywil timmywil added the Blocker label Sep 24, 2018
@timmywil timmywil self-assigned this Sep 24, 2018
timmywil added a commit to timmywil/jquery that referenced this issue Nov 11, 2018
Copy link

@gibson042 gibson042 commented Nov 12, 2018

That CodePen link is no longer working in IE11, let alone IE9, so I made a JS Bin:,js,output

The bottom line here is that something is still necessary, because IE getComputedStyle does in fact report box-sizing "border-box" for elements that don't actually exhibit border-box dimensions behavior, which the check against inline style can reveal. But the new wrinkle is that HTML table layout completely invalidates such a check, because all cells in a row or column have the same height or width (respectively).

I'm of the opinion that we should carve out an exception preventing border-box treatment of table cells in the absence of reliable box-sizing (e.g., ( support.boxSizingReliable() || !rtableCell.test( elem.nodeName ) && val ===[ dimension ] )).

timmywil added a commit to timmywil/jquery that referenced this issue Nov 12, 2018
timmywil added a commit to timmywil/jquery that referenced this issue Nov 12, 2018
@timmywil timmywil closed this in 315199c Nov 27, 2018
@lock lock bot locked as resolved and limited conversation to collaborators May 26, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

4 participants