Description
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.