You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
The text was updated successfully, but these errors were encountered: