F2F/Auckland 2011/Text-overflow

text-overflow support in svg

In making svg content there are many places where text doesn't necessarily fit into a predefined shape/area. Sometimes you just don't know beforehand how big the text will be. Complicating factors include e.g localization, user input and dynamically generated text segments. Simply leaving some additional space for these cases isn't enough.

The proposal for solving this problem is to add support for the 'text-overflow' property in svg text content block elements (<text> and <textArea>).

Definition

Name: text-overflow
Value: clip | ellipsis
Initial: clip
Applies to: block containers, in SVG: text content block elements
Inherits: no
Percentages: N/A
Media: visual
Computed value: as specified
Animatable: yes

This property specifies the behavior when text overflows the element it applies to that has 
‘overflow’ other than ‘visible’. Text may overflow for example when it is prevented from wrapping 
(e.g. due to ‘white-space:nowrap’ or a single word is too long to fit). Values have the following meanings:

clip
  Clip text as appropriate. Characters may be only partially rendered. 
ellipsis
  Render an ellipsis character (U+2026) to represent clipped text replacing however many characters are 
  necessary for the ellipsis to fit. Characters are dropped in reverse document source order: later characters
  are dropped first. If the ‘direction’ of the element is ‘ltr’ (‘rtl’) then the ellipsis is rendered to the 
  right (left) of the remaining characters on the line. If there is insufficient space for the ellipsis itself 
  to fit, then clip the rendering of the ellipsis itself. Implementations may substitute a more 
  language/script-appropriate ellipsis character. Implementations may render three dots "..." instead if the 
  ellipsis character is unavailable. The ellipsis is styled according to the element with text-overflow ellipsis
  (rather than any deeper descendants without text-overflow ellipsis). 

The term "character" is used in this property definition for better readability and means 
"grapheme cluster" [UAX29] for implementation purposes.

For <text> elements a 'width' attribute is added:

width = "<length>"
  The maximum length that the text is allowed to have before being subject to 'text-overflow' handling. 
  Whenever the sum of advances (including properties ‘kerning’, ‘letter-spacing’ and ‘word-spacing’ and 
  adjustments due to attributes ‘dx’ and ‘dy’ on ‘tspan’ elements) computed by the user agent exceeds 
  the given 'width' the <text> element is subject to 'text-overflow' processing.

Would dy really affect text-overflow? --heycam 23:44, 23 February 2011 (UTC)

For <textArea> elements there is already a 'width' and a 'height' attribute, so adding something like this should be enough:

Note that when text overflows the given area, for the last line in the textArea only, the 'text-overflow' property can affect the display of the <textArea>.

Issues to discuss

• Should 'overflow' have any effect on 'text-overflow' in svg?
  • Given that 'overflow' only affects elements that establish viewports in svg it seems a bit odd in the context of text elements. However, with it we could allow easy clipping of text fragments that overflow, which might be useful (it's already possible to do with clip-path though, though it's unconditional).
• How does this relate to 'textLength' / 'textAdjust'?
  • Because of 'textLength' being tied to 'textAdjust' it's hard to extend it to e.g use 'textLength' instead of 'width' as the width to clip to, because such content would break in older user agents.
• Should the ellipsis become part of the DOM if the text overflowed?
  • Proposal: no, it's purely visual.
• Should there be a DOM property for checking whether the text overflowed, or to fetch the stringlength (or the string itself) of the text that fit into the given area? Would that be useful?
• How should the ellipsis be handled wrt 'rotate', 'dx', 'dy' etc?
  • Proposal: Processed by the user agent as if it was the character that was replaced in the element that overflowed.
• How should trailing whitespace be handled?

• How do DOM methods that deal with character in text content elements deal with elided characters and the inserted ellipsis? --heycam 23:43, 23 February 2011 (UTC)
• I wonder if it is possible for a situation to occur where replacing some text with the ellipsis character would, due to kerning, cause too much or too little space to be used. I guess this would come up in regular CSS use of this property too. --heycam 23:49, 23 February 2011 (UTC)
• Perhaps this is also defined by CSS, but we need define how the ellipsis will be styled. It could replace more than one element's worth of text. --heycam 23:52, 23 February 2011 (UTC)