[csswg-drafts] [CSS Overflow] text-overflow ellipsis behavior in scrolling content (#10712)

schenney-chromium has just created a new issue for https://github.com/w3c/csswg-drafts:

== [CSS Overflow] text-overflow ellipsis behavior in scrolling content ==
This is in response to the discussion of issue #10418, where we were talking about where to position the ellipsis, and whether to update the text layout, when a text box with text-overflow: ellipsis is scrolled.

Chrome and Safari do not re-layout text when the content is scrolled, Firefox does do relayout and also supports the 2-value version of text-overflow where you can define what happens when the start of the text is clipped. This behavior is in https://drafts.csswg.org/css-overflow/#text-overflow

From a UI perspective the ellipsis exists to tell the user that there is invisible content that has been clipped. Hence, the Firefox behavior is the correct thing to do: it tells a user when there is extra content to the left or the right. Other browsers are implicitly assuming that overflow scroll is never mixed with text-overflow and the start of the line is never clipped. This seems like a flawed assumption.

This situation came up in a client call today, where the client has custom logic to paint a wash color over the text when it is overflowing left or right. That is a variant on the fundamental UI principal of providing feedback that clipping is happening.

I would support speccing the Firefox re-layout behavior, though I acknowledge that efficient implementation might be challenging.

Thoughts? @frivoal @bfgeek 

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10712 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 8 August 2024 00:41:17 UTC