Firefox, in an overflow:scroll or auto element, places the ellipsis immediately at the end of the line, even if that leaves a bit of extra room between the ellipsis and the text.
When you then scroll the element, as the spec requires, more content gets revealed.
The combination of these two things is: by pinning the ellipsis to the end of the line, this enables the ellpsis to visibly stays right where it is as you scroll. If you simply scroll (using two fingers on trackpad, the mouse's scrollwheel, or the scrollbar), that's not immediately visible, because Firefox will hide the ellipsis while you scroll, only to show it again once you release, but if you trigger the scrolling either programatically, or scroll by selecting, then you can see the ellipsis stay put while the rest moves.
Currently, neither Chrome nor Safari will reveal more content as you scroll, and instead they scroll the ellipsis with the text, revealing blank space. That in itself is a spec violation, but that's another story.
As long as you reveal more content as you scroll, which you should, I think the Firefox behavior is nice, but that placement of the ellipsis is a spec violation, because the spec says that you must:
place the ellipsis/string immediately adjacent to the applicable edge(s) of the remaining inline content.
How about we relax that requirement, and instead spec one of the two following options:
the ellipsis must be placed somewhere between the edge of the remaining inline content and the edge of the box, with the exact placement within that space being up to the UA
the ellipsis must be placed either at the edge of the remaining inline content or the edge of the box, at the UA's discretion
The CSS Working Group just discussed Position of the text-overflow ellipsis, and agreed to the following:
RESOLVED: Allow (but don't require) repositioning or fading
The full IRC log of that discussion
<matthieud> florian: there are differencies between browsers for text-overflow ellipsis
<matthieud> florian: spec says that you should remove enough text to place the ellipsis and that position is immediatly next to the remaining text
<matthieud> florian: firefox is inconsistent, sometimes it does something different but useful
<matthieud> florian: it places the ellipsis at the very end of the line box
<matthieud> florian: it's nice because if you scroll, you reveral some of the elided away text
<matthieud> florian: it avoid the ellipsis to jump back and forth during scrolling
<ChrisL> That does seem to be a better behavior, avoiding jitter
<matthieud> florian: but the spec says something else
<matthieud> florian: another behavior would be while you scroll you hide the ellipsis, compute and re-show the ellipsis to avoid jitter
<ChrisL> q+ to say we should not insist on jitter
<matthieud> florian: if we want ellipsis to be always visible, firefox behavior is nice
<iank_> q+
<Rossen4> ack ChrisL
<Zakim> ChrisL, you wanted to say we should not insist on jitter
<matthieud> ChrisL: the jitter in current implementation is not good
<miriam> q+
<matthieud> florian: in theory the spec says that all implementaiton should reveal text when you scroll, but only firefox does it
<matthieud> florian: but other browser don't so no jitter because they dont reveal text
<ChrisL> but they would
<Rossen4> ack iank_
<matthieud> iank_: jitter doesnt happen currently
<florian> q+
<matthieud> miriam: i like the behavior to allow scrolling
<matthieud> miriam: but what is the point of repositionning the ellipsis at the end ?
<matthieud> miriam: so it looks like current spec is good
<Rossen4> ack miriam
<Rossen4> ack florian
<matthieud> florian: if you scroll using the scrollbar or touchpad, the ellipsis disappear
<matthieud> florian: however by selecting the text not visible or scroll by script, the ellipsis remain visible
<matthieud> florian: maybe it should disappear all the time (but how does it would work with script?)
<matthieud> florian: for ian point, should we disallow reveal as you scroll ?
<matthieud> florian: current discussion might be moot for Chrome
<matthieud> iank_: I agree with miriam that if you are going to hide ellipsis while scrolling, the jittering point disappear as well
<fantasai> Options: A) Allow repositioning. B) Allow fading. C) Allow repositioning or fading.
<matthieud> florian: 2 options here : either allow the repositioning of the ellipsis like firefox is doing, or keep the spec as is which requires the ellipsis right next to the text and we should probably in/out to avoid jitter
<fantasai> D) Allow neither
<matthieud> fantasai: choices would be repositioning or fading or both or neither
<fantasai> RESOLVED: Allow (but don't require) repositioning or fading
Firefox, in an
overflow:scroll
orauto
element, places the ellipsis immediately at the end of the line, even if that leaves a bit of extra room between the ellipsis and the text.When you then scroll the element, as the spec requires, more content gets revealed.
The combination of these two things is: by pinning the ellipsis to the end of the line, this enables the ellpsis to visibly stays right where it is as you scroll. If you simply scroll (using two fingers on trackpad, the mouse's scrollwheel, or the scrollbar), that's not immediately visible, because Firefox will hide the ellipsis while you scroll, only to show it again once you release, but if you trigger the scrolling either programatically, or scroll by selecting, then you can see the ellipsis stay put while the rest moves.
Currently, neither Chrome nor Safari will reveal more content as you scroll, and instead they scroll the ellipsis with the text, revealing blank space. That in itself is a spec violation, but that's another story.
You can try this here (using Firefox): http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=12804
As long as you reveal more content as you scroll, which you should, I think the Firefox behavior is nice, but that placement of the ellipsis is a spec violation, because the spec says that you must:
How about we relax that requirement, and instead spec one of the two following options: