Re: [CSS3-UI] text-overflow:ellipsis (freshly rewritten/expanded and incorporated into editor's draft)

On 01/21/2011 10:53 PM, Tantek Çelik wrote:
> As planned, I have moved the skeleton definition of
> text-overflow:ellipsis from CSS3-Text[1] to CSS3-UI[2], and then
> expanded it to address new information and details.
>
> [1] http://dev.w3.org/csswg/css3-text/#text-overflow
> [2] http://dev.w3.org/csswg/css3-ui/#text-overflow<-- this is the
> one you want.

Looks a lot better than the first draft I saw. :) Some remaining issues:

# This property specifies the behavior when text overflows its element
# (e.g. has ‘overflow’ of hidden) when text is prevented from wrapping
# (e.g. due to ‘white-space:nowrap’ or a single word is too long to fit).

An element having 'overflow: hidden' is not an example of text
oveflowing an element. Not sure what was meant here.

Suggestion:

  | This property specifies the rendering of text that overflows its
  | block container, such as when text is prevented from wrapping
  | (e.g. due to 'white-space: nowrap' or an unbreakable word being
  | too long to fit).

If you want to trigger only on 'overflow: hidden', then that should
be a separate, normative sentence.

  | This property only has an effect when 'overflow' is ''hidden''.

If that's no longer wanted, but some existing implementations require
it, it should be a note:

  | <p class="note">Note that some existing implementations only honor
  | 'text-overflow: ellipsis' when 'overflow' is ''hidden'', even though
  | CSS3 UI does not require 'overflow' to have a particular value.

If the intended interaction with 'overflow' is uncertain, then leave it
undefined. Or partly defined, e.g.

  | UAs must honor 'text-overflow' when 'overflow' is ''hidden''.
  | UAs should honor the ''ellipsis'' value when 'overflow' is ''visible'',
  | but may instead treat ''ellipsis'' as ''clip''. It is not defined in
  | CSS3 UI what happens when 'overflow' has any other value.

# Render an ellipsis character (U+2026) to represent clipped text, just
# before where the text would be otherwise clipped.

"where the text would be otherwise clipped" introduces an ambiguity:
if the 'clip' property applies here (or some kind of future extension
for masking), does this change where the text would be elided? Or is
the behavior here based only on where 'overflow: hidden' would take
effect?

Consider also the case of nested elements:

<div style="overflow: hidden">
   <p style="position: relative; left: 10em; text-overflow: ellipsis">
     AreallylongwordthatgetsclippedbyDIVbutnotP
   </p>
</div>

Does the word get elided because it is clipped by its ancestor?
What if we move 'text-overflow: ellipsis' from the child to the
parent?

Please include relevant examples once you have resolved on the
required behavior so that the intended behavior is clear.

# (in the direction of the flow of the text being clipped)

I don't understand this phrase, what case is it addressing?

# The ellipsis is styled according to the element with text-overflow
# ellipsis (rather than any deeper descendants without text-overflow
# ellipsis).

The testcase for which this wording was introduced used inline elements,
to which 'text-overflow' does not apply. What happens here?

<div style="color: green; text-overflow: ellipsis">
   <p style="color: orange;">Reallylongwordthatgetselided</p>
</div>

Note: Your spec requires that the ellipsis be orange.

As roc mentions, anything you are intentionally leaving undefined
should be left explicitly undefined. You may also want to give
non-normative suggestions where the preferred behavior is known so
that implementers have some guidance on what to expect in the CSS4
definitions when designing their implementations.

~fantasai

Received on Monday, 24 January 2011 06:45:13 UTC