Workaround for issue with IE scrollWidth

问题:

I seem to have stumbled onto a bug in IE where the scrollWidth is off by 1px compared to the offsetWidth. The trigger to this seems to be dependent on the length of the text/characters in the element and only happens when overflow is set to something other than visible.

For context on why I am checking them against each other see this question: HTML - how can I show tooltip ONLY when ellipsis is activated

For an example of the issue see: http://jsfiddle.net/w5cwhjbf/2/

.base{
    font-size: 16px; 
    overflow: hidden;    
}

.wrapper{
    float: left;  
}

<div class="wrapper">
    <div id="div1" class="base">
        Why is my scrollWidth wrong in IE?
    </div>
</div>
<br style="clear: both;">
<br>
<button id="btn1" onclick="fnCheckScroll(div1,btn1)">Calculates Wrong</button>
<br>
<br>
<br> 
<div class="wrapper">
    <div id="div2" class="base">
        Why is my scrollWidth right in IE?
    </div>
</div>
<br style="clear: both;">
<br>
<button id="btn2" onclick="fnCheckScroll(div2,btn2)">Calculates Correctly</button>
<br>
<br>
<br>
Issue seems to be based on the character widths/font size resulting in I would assume a fractional value that in one case gets rounded up and the other rounded down.  The issue however does not ever cause scroll bars to appear (if overflow is auto).  Issue doesnt happen with overflow: visible.
  
        
<script type="text/javascript">
function fnCheckScroll(div, btn)
{    
   var iScrollWidth = div.scrollWidth;
   var iOffsetWidth = div.offsetWidth;
   var iDifference = iScrollWidth - iOffsetWidth;
   btn.innerHTML = ("Width: " + iOffsetWidth + "px  |  scrollWidth: " + iScrollWidth + "px  |  Difference: " + iDifference + "px"); 
}
</script>

You will notice in the example, though the first item has room to grow to whatever size it wants, its width is set 1px too short, or the scrollWidth reported is 1px too big, as well as the fact that no scrollbar is thrown (when CSS explicitly set to overflow: auto), IE knows somewhere in its code it is not actually overflowing.

Question is, what would be your suggested fix or workaround for this issue, as it seems like it randomly happens based on the characters/font/font-size in the div?

回答1:

It's hard to give the best solution without knowing how this applies to your specific problem with this bug. That being said, you could:

• Use a javascript bug-fix to adjust the attributes/styles/etc. if the two elements are different sizes.

  if(iDifference != 0) { /* make adjustments. */ }

• Use a tolerance check between the two elements; if the difference is less than or equal to 2px, then don't worry about it and process everything as normal.

  if(Math.abs(iDifference) <= 2) { /* no problem here! */ }

• Use the outer element for all computations, since that has the true width of the container.

• Use the inner element for all computations, since that will never cause an overlap with the outer element.

• Do nothing! Why fix it if it isn't broken?

It all depends on what you're trying to do and how the 1px gap is causing a problem.

回答2:

Found a workable workaround for the issue that would work in ie9+. Requires checking the elements getBoundingClientRect() width in addition to the scroll and offset width.

var boundingClientRectWidth = element.getBoundingClientRect().width;
var iScrollWidth = div.scrollWidth;
var iOffsetWidth = div.offsetWidth;

var amIOverflowing = (iScrollWidth > iOffsetWidth) && (boundingClientRectWidth == iOffsetWidth);

By check in IE if the boundingClient is forced to be the same size as the iOffsetWidth (instead of having a fractional width) we can ensure that we don't use the incorrect scroll width that is rounding up instead of down e.g. 273.36...

See this jsfiddle: http://jsfiddle.net/gskfke6L/1/

回答3:

Try to set the padding-right: 1px; for the class .base.

.base{
    font-size: 16px; 
    overflow: hidden;
    padding-right: 1px;    
}