- From: Bert Bos <bert@w3.org>
- Date: Tue, 5 Aug 2008 14:58:09 +0200
- To: www-style@w3.org
On Friday 01 August 2008 15:48, Joeri Sebrechts wrote:
> 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.
Reasonable.
> * The ellipsis does not truncate characters halfway.
Good.
> * 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.
Another subtle point is that the ellipsis on the first line should be
after the "a" and not after the space. The space is not really a
character (except in preformatted text), but a piece of mark-up that
creates a word separator.
> * The ellipsis style comes from the overflowing element, not the
> element that forces overflow
Good.
> * Text-overflow does not inherit automatically
Fine.
> * 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.
> * Chinese text ellipsis is rendered with three dots, not six dots
> (which is more appropriate)
Beyond my expertise...
> * 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.
Good.
> - Different
> * Ellipsis character
>
> > IE, Opera: three dots
> > Safari: ellipsis character (U+2026)
> > Correct behavior: ellipsis if possible, fallback to three dots
Ellipsis looks better in proportional fonts, but not in monospace fonts.
That said, using ellipsis even there is good enough in my opinion.
>
> 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.)
> * 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
Not sure that is what you are saying, but I think there should never be
anything between the ellipsis and the boundary of the box: You lay out
the lines using the bidi-algorithm, and then remove characters from the
end of the *visual* lines:
+-----------------------------------+
| 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 |
+-----------------------------------+
> * 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
Not sure. I would expect an inline block to be treated very much like a
letter. E.g.:
+-----------------------------------+
| 3-line |
| Here is a sentence with a high i|n the middle.
| button |
+-----------------------------------+
becomes
+-----------------------------------+
| |
| Here is a sentence with a... |
| |
+-----------------------------------+
> * 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
Indeed.
I can imagine that slow devices may temporarily remove the ellipsis
during the scrolling and put it back in when the scrolling stops. (Even
slower ones may move the scrollbar but not move the content at all
until the scrollbar stops moving.)
> * 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
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...
>
> 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.
Possibly, but until somebody actually tries to write that wording, we
won't know :-)
> - 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 that's what the text meant, it's just saying it in a somewhat
ambiguous way.
> 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.
I would remove inline blocks, too, if that is needed to make room for
the ellipsis.
But otherwise I agree: If you cannot remove enough characters to make
room for the whole ellipsis, then display as much of the ellipsis as
will fit.
> - 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.
It probably doesn't matter much what the precise definition is, as long
as it works in the "obvious" cases: if there is non-leading white space
left on the line after removing sufficient characters to make place for
the ellipsis, then remove some more characters, up to that white space,
and remove the white space, too. Whether dash-separated words are
separate words or not, or whether parenthis(z)ed and/or slash-separated
words are separable seems rather unimportant.
You may want a heuristic limit on how long "words" can get, to avoid
that THISVERYLONGCHINESESENTENCEWITHTWO english words
GETSCLIPPEDALLTHEWAYTOTHOSETWOENGLISHWORDS.
But not including 'ellipsis-word' is fine with me.
> - 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.
The typical choices are arrow-like symbols (→ ▶ ➩), I would expect.
Unicode has many of those. So I won't miss images that much.
> - 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).
Or arrows...
Or the word "[More...]" in the case of vertical overflow...
> - 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 think it is trying to say that a text like
<div style="width: 200%; text-overflow: ellipsis">
<p>This is an overflowing paragraph.
<p>And this is another.
</div>
may be cut off like this
This is an o...
And this is...
even though the property was not set on the Ps. It's a bit subtle,
because the ellipses look like they're part of the Ps, but the Ps don't
actually overflow; it's their parent DIV that does. (In fact, the Ps
have 'text-overflow: clip', but that doesn't remove the ellipses.)
> - 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.
I think the "end" and "after" may refer to horizontal and vertical
overflow. That is: the first value replaces letters in a line when the
line is too long, the second value replaces lines when there are too
many lines. E.g.,
text-overflow-ellipsis: "..." "v v v"
causes
+----------+
| A text th|at is
| both too |wide
| and too h|igh
| for the b|ox
| that it i|s in
+----------+
will be clipped.
to become
+----------+
| A text...|
| both t...|
| and to...|
| that i...|
| v v v |
+----------+
>
> 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.
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
Received on Tuesday, 5 August 2008 12:58:54 UTC