text-overflow: ellipsis

Hello,

Following from the discussion and test cases at
https://bugzilla.mozilla.org/show_bug.cgi?id=312156 I'd like to see a
specification happen for text-overflow: ellipsis so this can get implemented
in firefox.

As you know, this is implemented in IE, Opera and Safari. They have however
implemented it inconsistently, so it is important to clearly define the
correct behavior.

First, I'll list the existing browser behavior (see the bugzilla ticket for
the test cases that led to these conclusions). Next I'll list my views on
how the old spec should be modified.

Browser behavior:
- Common
  * The ellipsis appears only for inline text, not when images or other
types of blocks overflow an element.
  * The ellipsis does not truncate characters halfway.
  * The ellipsis renders by visually removing characters from the overflow
boundary to make space, and then rendering the ellipsis after the last
character that was not removed.
  * The ellipsis style comes from the overflowing element, not the element
that forces overflow
  * Text-overflow does not inherit automatically
  * Text-alignment does not influence overflow rules, and therefore does not
influence ellipsis placement
  * Chinese text ellipsis is rendered with three dots, not six dots (which
is more appropriate)
  * Text-overflow: ellipsis must be explicitly defined (or explicitly
inherited) before it is used. The default behavior for all elements is to
not show an ellipsis.
- Different
  * Ellipsis character
    > IE, Opera: three dots
    > Safari: ellipsis character (U+2026)
    > Correct behavior: ellipsis if possible, fallback to three dots
otherwise
  * Right-to-left text
    > IE: reversed direction, with ellipsis on the left
    > Opera: strange behavior
    > Safari: no ellipsis
    > Correct: assuming ellipsis on the left, because that's where the
overflow occurs
  * Right-to-left text causes overflow in left-to-right segment
    > IE: ellipsis rendered according to LTR rules (at the right edge of the
RTL text)
    > Opera: strange behavior
    > Safari: no ellipsis
    > Correct: assuming ellipsis rendered according to LTR rules, because
that's where the overflow occurs
  * Inline segment that triggers ellipsis is too narrow and preceded by a
block (ellipsis won't fit unless the block is removed)
    > IE: ellipsis rendered after the block, even if it doesn't fit
    > Opera: ellipsis rendered on top of the block
    > Safari: no ellipsis
    > Correct: assuming ellipsis after the block, because removing or
truncating the block would cause very odd rendering
  * Overflow: auto
    > IE: scrolling moves the ellipsis so more text is revealed
    > Opera, Safari: scrolling does not move the ellipsis, more text is not
revealed
    > Correct: assuming scrolling moves the ellipsis and reveals more text,
because ellipsis should be a visual hint of obscured content only
  * Javascript mouse event on ellipsis
    > IE, Opera: event triggers on element that causes overflow
    > Safari: event triggers on overflowing element
    > Correct: assuming event triggers on element that causes overflow,
because ellipsis is a visual hint only, and is not an element by itself

With regards to the existing spec at
http://www.w3.org/TR/2003/CR-css3-text-20030514/#text-overflow-props
- The ellipsis is shown if there is hidden content in the overflowing
element, and the overflow boundary is straddled by an inline box. The
existing spec wording for when to show the ellipsis could be simplified I
think.
- The spec says that the ellipsis should be rendered before the overflow
boundary, but this is not the browser behavior (rendered after the last
non-removed character), and also not the intuitive behavior (in written
text, the ellipsis is always placed right after the text that is truncated).
I think the correct behavior is to visually remove grapheme clusters until
enough space is available for the ellipsis, or until a block boundary is met
(from an inline block, or the boundary from the overflowing block), and to
then render the ellipsis at the insertion point of the last removed grapheme
cluster. That's intuitive, and mostly consistent with the behavior as
implemented.
- The ellipsis-word mode is not implemented, and the implementability
depends on a straight-forward definition of what a word is. Is there such a
definition? If not, I would suggest not including this in the spec at this
point.
- The ellipsis is styled as if it was a part of the run of text of the
overflowing element (it has the style of the overflowing element). It's
pretty straightforward in this case to let users decide on a custom string
to use instead of an ellipsis symbol, and use that instead of the three
dots. But to allow an image to be used, as the current spec provides for, is
a lot less obvious. What do you do if the image does not fit? Unless there
is a simple and accurate answer to this question, I would suggest not
including this in the spec at this point.
- There were suggestions earlier on to drop the ability to specify an
alternate string to use instead of the ellipsis character, but I think this
would be a handy feature because then you'd offer a way to deal with varying
conventions on how a visual hint of obscured content must be rendered in
different locales (e.g. chinese).
- The ellipsis is only shown for the element with the text-overflow style.
The whole bit in the spec about positioned children is confusing and seems
incorrect or at least non-relevant.
- I don't quite get the point of the bit about being able to provide two
ellipsis values, one for at the end of the element, and one for after the
element. I think it is best to treat ellipsis as a purely visual hint, and
this part of the spec seems to make it something that would affect layout of
other elements.

In general I think the spec should use the IE behavior as a baseline, as
this seems consistent and well thought-out, and is obviously implementable.
Where the implementations diverge from IE, it's obvious or at least
defendable that IE's behavior is the correct one. The one exception may be
that IE always renders the ellipsis with three dots, where it should try to
render it with an ellipsis entity if available.

Any thoughts, suggestions, ideas?

I'm willing to try my hand at authoring the spec, but as I'm not well-versed
in W3-ese I would need guidance to make something sensible out of it.

Thanks for your patience in reading all the way through this mail,
Joeri Sebrechts