- From: Stephen Chenney via GitHub <sysbot+gh@w3.org>
- Date: Thu, 08 Aug 2024 00:41:16 +0000
- To: public-css-archive@w3.org
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