Re: text-overflow: ellipsis

On Tue, Aug 5, 2008 at 2:58 PM, Bert Bos <bert@w3.org> wrote:

> >   * 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.
>
> Good.
>
> But what happens if there is no character left after you remove the
> overflowing ones?
>
>    +----------------+
>    |   Here is a rig|ht-aligned text
>    |                |that overflows.
>    +----------------+
>
>    +----------------+
>    |   Here is a... |
>    |             ...|
>    +----------------+
>
> The second line doesn't have any character that is not removed.
>

It's actually quite difficult to get this situation, since text-align right
will not move text beyond the overflow boundary if it can help it. I tried
approaches with floated elements and inline blocks pushing the second line
of content to beyond the overflow boundary. In this case some browsers in
some cases simply refuse to put the overflowing inline content on the same
line (it gets pushed to the next). I couldn't get IE to not do this. When I
did get browsers to do this, safari renders the content without ellipsis
(truncated), and opera just renders a lonely ellipsis, completely replacing
the inline content that overflows.

To me this is the same question as "what happens when the overflowing
element is too narrow to contain anything but the ellipsis?"

The answer is:
- For IE and Opera: render it anyway, possibly truncating it
- For Safari: render it only if there's at least one letter visible next to
the ellipsis

I like Safari's solution better, though there are arguments to be made
either way.

>   * Text-alignment does not influence overflow rules, and therefore
> > does not influence ellipsis placement
>
> I don't understand this remark. Text alignment clearly influences the
> position of each letter, including the letter after which the ellipsis
> is placed.


What I meant is that right-aligned LTR text still overflows to the right,
and that the alignment algorithm's behavior of trying to avoid overflow as
long as possible means that if the element is too narrow to fit the content,
it will render identically to how it would if left-aligned. Putting a style
"text-align: right" on a div containing a single overflowing line does not
change the visual appearance of that div, nor does it affect ellipsis
placement in the browsers that implement it.


> >
> > 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
>
> I think where the overflow occurs has nothing to do with the text
> direction. A right-aligned text overflows on the left and vice-versa.
> And once you scroll to the end of the text, all the overflow is on the
> other side. And, indeed, while scrolling, there is overflow on both
> sides.
>
> And a centered line may overflow on both sides. (For reasons of buggy
> implementations, centering is not possible in level 2, but we'll add it
> back in level 3.)


Overflow in current browsers always happens in the text direction, not
according to the alignment. Right- and center-aligned LTR text overflows to
the right only (tested this with a text-align style on an overflowing div).


>    +-----------------------------------+
>    | This is a sentence with some SDROW| WERBEH inside.
>    +-----------------------------------+
>
> becomes
>
>    +-----------------------------------+
>    | This is a sentence with some SD...|
>    +-----------------------------------+
>
> and *not*
>
>    +-----------------------------------+
>    | This is a sentence with some ...H |
>    +-----------------------------------+


That's what I meant.


> Not sure. I would expect an inline block to be treated very much like a
> letter.


This would lead to very unintuitive renderings if you have a wide
inline-block (as is likely). An ellipsis might end up rendered close to one
edge of the overflowing element while it actually would indicate overflow at
the other edge. Either that or the inline block would have to be truncated,
which is even worse behaviorally if you ask me. The nice thing about
visually removing only characters in inline boxes is that it removes only
the space needed for the ellisis, more or less.


> The principle, I think, is that the ellipsis should be treated as much
> as possible as the letter just before it, because visually they form
> one whole. If the full text was "abcdef" and adding the ellipsis makes
> it into "ab...", then the ellipsis should have the same style as
> the "b" and if hovering or clicking the "b" causes something to happen,
> than so should hovering or clicking the ellipsis.
>
> But if the "b" has a border, then maybe that should not be the case.
> I.e., the border should not move to include the ellipsis. Or maybe it
> should. I'm not sure...


As Rob pointed out, there's a matter of prior browser behavior here. IE,
Safari and Opera consistently use the style of the overflowing element for
the ellipsis. This may not even be such a bad thing, because this allows
you, for example, to render the ellipsis in a different color from the text
that triggers overflow, to visually set it apart from that text and make it
obvious it is a hint of overflow, not a part of the regular content.

On another topic: should ellipsis intelligently change behavior depending on
language? Personally I would say "no". It would make the implementation more
complex, and it would make the feature less predictable to authors (and
speaking as a professional web app developer, I really want predictability).
Besides, the most common use cases for language-sensitivity can be simulated
by specifying an alternate ellipsis string, like the six dot ellipsis for
chinese.