1226695 - scrollWidth returned with insufficient precision

Status: RESOLVED WONTFIX

(Core :: DOM: CSS Object Model, defect)

Description

[travtrilogi]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36

Steps to reproduce:

See examples in jsfiddle and codepen:
http://jsfiddle.net/TravStone/gqdzcyvy/22/
http://codepen.io/trav_stone/pen/qOvzwN

Essentially, set 'text-overflow:ellipsis' and then adjust the font-size (or presumably a number of other possible values) so that the text becomes ellipsed


Actual results:

Text becomes truncated, browser appends an ellipsis. However, when examining the width with any of the available JS methods, values reported SHOULD NOT be causing an ellipsis. This makes it impossible to detect the ellipses with JS in certain circumstances.


Expected results:

Browser should report the width values as they're used by the ellipsis algorithm.

Comment 1

[travtrilogi]

Sorry, should have noted that this issue also exists in Chrome, but dos not seem to exist in IE10+

Comment 2

[Boris Zbarsky [:bzbarsky]]

Per spec, scrollWidth returns an integer.  So if your actual width is not an integer number of pixels, you'll get a truncated value that's too low.

I think there were some attempts to change scrollWidth to return a double instead of an integer; I'm not sure whether they got anywhere in terms of web compat...

Comment 3

[travtrilogi]

Thanks Boris. I did note that part about the integer, but when I tried using the suggested approach for fractional values (https://developer.mozilla.org/en-US/docs/Web/API/Element/getBoundingClientRect) per MDN scrollWidth entry (https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollWidth), as you can see in the fiddle/pen, the values are all the same.

Perhaps what's needed is a separate API method for 'text-overflow: ellipsis'; something like element.textEllipsed() which could return true or false, and optionally the floating value used to determine it, or something along those lines.

Do you know how I might go about proposing such a thing? Thanks again!

Comment 4

[Boris Zbarsky [:bzbarsky]]

I'm not sure what your fiddle/pen are trying to show: they seem to be looking at getBoundingClientRect on the _cell_, not on the kids inside that actually overflow and get ellipsized.  Of course the size of the cell is 100px; you styled it that way explicitly.  What you're trying to find is the width of the kids.

The problem you're having, at least in part, is that the kids are just text, not elements...

> Do you know how I might go about proposing such a thing? 

Probably mailing [e-mail]

Comment 5

[travtrilogi]

Thanks Boris. You're correct, but that still leaves the unsolved problem of how to determine, dynamically, what text strings are being truncated by the browser. I'd prefer to avoid adding more markup just to make that determination... and since IE10 in this case (surprisingly) appears to get things right, it does seem a bit of a bug.

Thanks for the suggestion on the feature proposal; will follow-up on that pending the outcome of this bug (and the one I've logged for Chrome).

Comment 6

[Simon Pieters [:zcorpan]]

Yeah, scrollWidth was reverted to "long".

https://lists.w3.org/Archives/Public/www-style/2015Feb/0195.html

Comment 9

[Mats Palmgren (inactive)]

I tend to think we should resolve this as wontfix given the www-style discussion linked in comment 6, where Chrome folks said it wouldn't be web-compatible to change the type for these widths/heights. That's likely still true.

Also, these days you can workaround it by using Range.getBoundingClientRect() instead. Just create a Range object, initialize it include all node children of the element you're interested in, then call getBoundingClientRect() on the range to get the union of all the border boxes of the children. That should cover most of these use cases.

In any case, we won't fix this unless there's consensus about changing the spec first (which, frankly, I don't see happening).
If getBoundingClientRect() is insufficient for your use case then please file a spec issue at https://github.com/w3c/csswg-drafts/issues/ about it.