csswg-drafts
csswg-drafts copied to clipboard
[css-overflow] It should be detectable whether an element ellipsized the text
Current spec: https://www.w3.org/TR/2018/WD-css-overflow-3-20180731/#auto-ellipsis Chrome issue: https://bugs.chromium.org/p/chromium/issues/detail?id=980476.
Background:
The use of text-overflow: ellipsis
will make overflowing text hidden from users. At the very pixel where the ellipsis appear, the overflow is undetectable. This means that some characters will be permanently hidden from users, and that there's no workaround for developers.
Issue: This issue only appear at the exact pixel where ellipses appear. For some text content, rounding of scrollWidth will make queried scrollWidth, clientWidth or DOMRect identical, despite the text-overflow.
Here is a codepen where overflow appears despite scrollWidth == clientWidth
:
https://codepen.io/anon/pen/XvrzQV
This issue makes text-overflow: ellipsis unusable in some contexts. For example in the healthcare, where doctors must have complete access to all information at all times.
The spec should mandate that if an element has ellipsized text, then that must be detectable.
Ah, this is a result of subpixel widths not being detectable via those legacy APIs. :(
I know we've tried to do versions of these sizing APIs that return fractional pixels, but have had to revert due to webcompat.
This issue makes text-overflow: ellipsis unusable in some contexts. For example in the healthcare, where doctors must have complete access to all information at all times.
Can you elaborate as to how ellipsis is used at all in these contexts? Is it something like, you can ellipsize by default, but expand it on click to show the full information without ellipsises? (And then, due to the rounding, still end up with ellipsises on the expanded content.)
An API with fractional accuracy would solve all my problems!
Of course, a bit more background:
I'm building native apps for healthcare: journal systems, lab-orders, theater management, etc. The one thing those views have in common is that they have a lot of text. And the doctors/nurses want that text dense. We must use text-overflow: ellipsis
for that density.
To display ellipsized content, we've developed an Angular directive that opens an overlay. The gist:
// in onMouseenter
if (eventTarget.scrollWidth > eventTarget.offsetWidth ) {
this.overlay.open();
}
It looks like something most IDEs have in their sidenavs. The problem is that since we can't always detect the overflow, sometimes there's ellipsized content that doesn't trigger the overlay.
Ah gotcha. Yeah, that's a problem.
Agenda+ to discuss this problem, particularly with whether we can figure out a way to expose the proper subpixel widths despite our previous failures.
FWIW, wpt.fyi solves a very similar problem using just css like:
code:hover {
width: max-content;
}
(See the "Subtest" column in a test with long names like this, and hover over them).
You can probably detect this already via script by setting width: max-content
, measuring it with an API that gives you fractional values like getBoundingClientRect()
, then comparing it with the non-min-content measurement.
Nice @emilio, I updated the codepen with your idea. Hover the ellipsized text to see the result.
https://codepen.io/anon/pen/Voeyod
Setting $0.style.maxWidth = 'max-content';
and then doing $0.getBoundingClientRect();
does give fractional accuracy on overflowing text.
Does that mean this issue is solved?
The CSS Working Group just discussed It should be detectable whether an element ellipsized the text
.
The full IRC log of that discussion
<AmeliaBR> Topic: It should be detectable whether an element ellipsized the text<AmeliaBR> github: https://github.com/w3c/csswg-drafts/issues/4123
<AmeliaBR> TabAtkins: Issue comes down to some APIs not reporting subpixels, which can give weird results sometimes. That's worth addressing But I think we can close main issue.
<AmeliaBR> florian: Worth mentioning that the use case is JS code to *show* ellipsized text. If more browsers offered that as a built-in feature, wouldn't need to hack around it.
Issue is still reproducible as I see because scrollWidth returns rounded value. At the moment, there is no precise way to determine whether the ellipsis is displayed or not. Showing ellipsis text relayed on JS not always fit if the element is the cell of big table, because of browser performance
Agree with @AndriiBespalyi, bcs, for now, we have no stable and easy API to get this state and calculation from JS is not connected with logic, how it works under the hood.
+1
If config a custom style tooltip, the only way is create it by a normal HTML element with custom style.
So the max-content
solution isn't possibile for global tooltip detect.
And if the tooltip offered by browser, we need to implement styling API, it brings more problems.