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 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 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 commented Sep 3, 2018

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

Copy link

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
@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.