Re: text-overflow: ellipsis

The purpose of ellipsis is to indicate content on a line that is hidden by
overflow.

So, the way I see it, if the multi-line scenario is such that only the last
line is partially obscured (because the other lines wrap), only the last
line should get an ellipsis. But if every line is partially obscured, then
every line should get an ellipsis.

I've been working on a clear-cut definition of how and when to show it, but
it needs a bit more fine-tuning before I post it here.

On Tue, Aug 12, 2008 at 8:52 PM, Frode Børli <frode@seria.no> wrote:

> Just as a side-note: have multiple line behaviour been discussed? I am
> thinking that if I create a div, with a fixed height and width - i want
> ellipsis at the end of the last line.
>
> Frode Børli
>
> 2008/8/6 Joeri Sebrechts <joeri@sebrechts.net>
>
>  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.
>>
>>
>
>
> --
> Best regards / Med vennlig hilsen
> Frode Børli
> Seria.no
>
> Mobile: +47 406 16 637
> Company: +47 216 90 000
> Fax: +47 216 91 000
>
> "Great spirits have always found violent opposition from mediocrities. The
> latter cannot understand it when a man does not thoughtlessly submit to
> hereditary prejudices but honestly and courageously uses his intelligence."
> - Albert Einstein
> "You see, wire telegraph is a kind of a very, very long cat. You pull his
> tail in New York and his head is meowing in Los Angeles. Do you understand
> this? And radio operates exactly the same way: you send signals here, they
> receive them there. The only difference is that there is no cat."
> - also Albert Einstein
>