W3C home > Mailing lists > Public > www-style@w3.org > October 2009

Re: [css3-text] Suggestion for text-overflow:shrink

From: Bert Bos <bert@w3.org>
Date: Wed, 7 Oct 2009 15:33:33 +0200
To: www-style list <www-style@w3.org>
Message-Id: <200910071533.33557.bert@w3.org>
On Tuesday 06 October 2009, Tab Atkins Jr. wrote:
> I'd like to propose a new value for the text-overflow property:
> shrink.  This value would, when text overflows its container, reduce
> the size of the text using whatever methods the UA deems most
> appropriate (direct font-size reduction, reducing the space between
> letters, etc.) until the text no longer overflows.
>
> This would be useful on my current project, where I have a
> fixed-width dropdown menu that takes its heading from the selection
> you make. It's very possible for text that reasonably fits within the
> menu (at its normal size) to overflow the heading (at an increased
> font-size and slightly wider font).  Flowing down to a separate line
> is not possible for design reasons, and text-overflow:ellipsis is
> unacceptable for some of the menus (such as the date selector) that
> need to present their entire value to be sensical.

This has overlap with something we discussed in the past[1] under the 
name of 'text-align-last'. A property of that name exists already in 
XSL1, but the CSS version (and the XSL2 version), would offer extra 
features.

Its purpose is to set the justification for the last line of a block of 
text (which may also be the only line, of course, as in your menu 
example), but unlike the 'text-align' property, this property may 
change more than than just the spacing between letters. In particular, 
it would offer an option to change the font size in order to achieve a 
fully justified line.

To avoid extremely large or extremely small text, there would be 
new 'min-font-size' and 'max-font-size' properties as well. If the font 
can't be scaled far enough, it would only be scaled as far as it can. 
So, to create a heading that exactly fills a line (within reasonable 
limits), you could write rules such as these:

    h1 {
      text-align-last: size; /* Justify by varying the font size */
      min-font-size: 0.6em;  /* Protect against too small fonts */
      max-font-size: 4em;    /* Reasonable maximum size */
    }

Your menu example could be approximated by this:

    .menu {
      text-align-last: size; /* Vary the font size */
      min-font-size: 0.6em;  /* Protect against unreadable fonts */
      max-font-size: 1em;    /* Don't ever increase the font size */
    }

This allows the font to shrink, but not to grow.

Our published proposal isn't very explicit on the algorithms, but it 
implies that changing the font size and line breaking are 
interdependent: first try to fit the whole paragraph on one line by 
shrinking the font as far as possible, fall back to traditional line 
breaking only if that fails, and finally increase the font of the last 
line to try and fill the width.

If you don't want line breaking at all, you can add 'white-space: 
nowrap', in which case a line that can't be shrunk enough will overflow 
rather than wrap.

The 'letter-spacing' property already allows you to permit or inhibit 
the varying of interletter spaces ('letter-spacing: normal' 
vs 'letter-spacing: 0'). We didn't want to give the designer more 
control than that, because of the expected complexity, although using a 
TeX-like "penalty" system was talked about. (It would associate 
numerical penalties with word spaces, interletter spaces and font 
sizes, so you can express that, e.g., shrinking a word space by half is 
as bad as stretching an interletter space by 5%, or as increasing a 
font size by 40%.)

We have never discussed automatic widening/narrowing of glyphs, I 
believe (apart from kashida for Arabic script). It is probably 
technically possible with modern scalable fonts, but there is no 
typographic tradition[2] to base a CSSĀ model on. It would require some 
effort and patience to come up with a good set of properties.

The only example I know of automatic stretching is Hemann Zapf's Hz 
program, which (almost) imperceptibly changes the width of glyphs in a 
smart way (i.e., without thickening the stems) to help justify lines. 
But its main goal is expressly to make adjacent lines look the same, 
while your menu example has no such constraint at all.

[1] 
http://www.w3.org/TR/2003/CR-css3-text-20030514/#last-line-alignment-prop

[2] Some people claim that early printers, such as Gutenberg, did 
consciously select wider or narrower letters to justify lines better. 
Gutenberg's narrow letters weren't just narrower, however, they 
actually had different shapes. Anyway, the tradition has disappeared 
since. See
http://www.typografi.org/justering/gut_hz/gutenberg_hz_english.html

>
> This property does have the possibility of rendering text completely
> unreadable by shrinking it too much, of course.  I'm not sure if this
> is actually a problem in practice, or if a simple warning along the
> lines of "Only use this value when the text is expected to overflow
> the box only slightly." would be sufficient.

That's why we added 'min-font-size' and 'max-font-size'.

> (Better ideas for how to solve my given use-case would be appreciated
> as well, if they exist.)



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 Wednesday, 7 October 2009 13:34:06 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:21 GMT