Re: text-overflow: ellipsis

With apologies for the late follow-up, here goes my attempt at formulating
some text for text-overflow: ellipsis.

First of all, a list of what I think the desired behavior should be:

>From the behavior of the current implementations:
- Show a hint on lines where text gets clipped when it overflows its
container, as a visual indication of the hidden text.
- The hint should be close to the overflow boundary, and right after a
character in the line (as if it was part of the flow of text).
- The hint should be shown in the style of the overflowing block, not the
text it replaces. This may be a topic of debate, but it is what current
implementations do, and it means the hint can be predictably styled.
- The hint should purely visually replace the last few visible characters on
the line, depending on how much space is needed to show the hint. This means
that the hint is only shown if there are in fact characters right before the
overflow boundary (so for an image at the overflow boundary, the hint is not
shown). This also means that the content of the document is not affected.
- The hint is only shown when the overflowing block is the direct
block-level ancestor of the inline text that overflows the block.In other
words, an overflowing div, containing a table, containing text, will not
show ellipsis because it's not the table that overflows.

Not current behavior, but I think it should be:
- Scrolling the container must redraw the hint at a different position.
- RTL doesn't affect the algorithm other than mirroring it. A hint is shown
at the left edge for RTL text just as it is shown at the right edge for LTR.

---------------

Name:    text-overflow
Value:    clip | ellipsis | <string>
Initial:    clip
Applies to:    block-level, inline-block elements and table cells
Inherited:    no
Percentages:    N/A
Media:    visual
Computed value:    as specified

This property determines what kind of visual hint is rendered to indicate
text that overflows, and is clipped by, its direct block-level container.

This effect is visual in nature only, and does not influence the document's
content. The textual overflow hint is rendered for each overflowing line of
text by visually removing consecutive grapheme clusters starting from the
overflow boundary until enough space has been cleared to fit the hint, and
then placing the hint at the same position as the last removed grapheme
cluster. The hint's style is that of the overflowing container.

If it is not possible to visually remove sufficient content to fit the hint,
the hint is placed at the position of the last grapheme cluster that could
be removed. If there are no grapheme clusters at the overflow boundary, or
if there is not enough content in the line to fit anything but the hint, it
is not rendered at all, and no content is visually removed.

Values have the following meanings:

clip
    Clip text as appropriate. Glyphs may be only partially rendered.
ellipsis
    Render an ellipsis (U+2026) to represent clipped text.
<string>
    Render the given string to represent clipped text.

--------------

Now, there are some things I'm not fully clear on:
- Is grapheme cluster really the right term here?
- Should ellipsis appear also for indirect block ancestors? IE does this in
some cases, but not all. Is this feasible for implementors to do in all
cases? If we do include indirect ancestors, doesn't this mean text in inline
SVG and other types of mixed content documents must get ellipsis if it's
inside an overflowing html block?
- Since the hint takes the style from the overflowing block, not from the
line of text it is in, what to do when the hint is too high to fit on the
line? The existing implementations just render the ellipsis anyway, without
changing the line height. This may cause it to obscure content on other
lines. Going over the list of solutions I can think of:
  * Taking the style from the text that the ellipsis is rendered after.
Wrong because it means you can't really style the ellipsis or predict its
rendering, and because I'm assuming it makes implementing this much more
complicated.
  * Clipping the hint if it moves outside the line box. Also wrong for the
obvious reasons.
  * Not rendering the hint if it moves outside the line box. I don't like
this because it means ellipsis becomes less predictable.
  * Increasing the line height. I don't like this either, because it means
the line height depends on what is at the edge of the overflowing block
(line is high if text is there, line is not high if an image is there),
which makes line height very difficult to predict, as well as complicating
implementation (or so I presume).
  * Telling authors to just "don't do that". I'd go with this. The spec
can't solve every way authors can shoot themselves in the foot.
- position: relative is somewhat of an open question. What happens when you
"move back" a span from beyond the overflow boundary to be across the
overflow boundary. Should the hint get rendered twice?