You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
.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 elem.style
valueIsBorderBox = valueIsBorderBox &&
( support.boxSizingReliable() || val === elem.style[ dimension ] );
val is coming from window.getComputedStyle().width but elem.style['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.
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.
The text was updated successfully, but these errors were encountered:
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 === elem.style[ dimension ] )).
timmywil
added a commit
to timmywil/jquery
that referenced
this issue
Nov 12, 2018
Description
.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
andfixedColumn.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):val
is coming fromwindow.getComputedStyle().width
butelem.style['width']
is coming fromstyle
attribute (as I understand it). And when these two values are equal it leads jQuery to believe thatval
is aborder
box size already and doesn't add padding.Changing the width of the second row cell to
191px
or189px
results inouterWidth()
of the problematic cell (th
) to200
.Link to test case
https://codepen.io/rgavrilov/pen/KeqxJp
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.
The text was updated successfully, but these errors were encountered: