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

I missed this discussion but I thought about this and discussed with Sylvain briefly... Here are my thoughts (no commitment to implement just yet):

-- Some use cases will find this very valuable (I think there is much more use than just for one line of text):

 - Title (e.g. an article title that should fit in one line)
 - An article that should fit in one column
 - And advertisement text that needs to fit in a given box, regardless of variations of font size
 - A slide in a presentation

-- Observation: all use cases so far are text
 - Same functionality for images exists already so it is tempting to limit the feature to text...
 - ... 
-- Interop goals: all implementations should produce predictable bounding box
 - ideally predictablility requirement wouldn't prevent UA from innovating and doing a "better fit" (e.g. by micro adjustment of character widths or line height)

With these requirements, here is what I think would make it a viable feature:

1) The property is 'overflow'
2) new 'overflow' values (I don't know if all values are needed - that's a decision independent from the rest of it): 

 overflow:shrink -- shrink but not stretch  
 overflow:stretch -- stretch but not shrink
 overflow:fit    -- shrink or stretch for exact fit
 
3) the new values do not apply to 'overflow-x' or 'overflow-y'
4) the new values do not apply unless both width and height (or max-width/max-height) are specified
5) the new values make the block a Block Formatting Context

Why 'overflow' and fixed size? I think requiring a fixed size container would be a reasonable restriction that allows UA to be innovative but at the same time does not create a hard interop issue. This may not be the only way to achieve that but this would definitely make implementation of a "shrink" block have no effect on its size. 
I do realize that there it makes a one-line scenario more complicated - the author has to specify the height of the box (probably to match a one-line box) which may be tricky. There should be a variation of these rules that's easier to use.

Should this apply to non-text (e.g. inline images)? I think the spec should not be prescriptive about it. It would make sense to leave images alone when making tiny adjustments to text (e.g. if 1% compression of the font makes it fit, it is good to avoid 1% resize of images - that would cause unnecessary resampling). But if images are excluded there is no guarantee that overall content fits. I think this kind of heuristics is best left for UA.

I know that what I am describing is not exactly what was asked for... but it could apply the idea to a few more things and be quite useful. And it doesn't seem too difficult to implement (no promises yet) -- although it most certainly involves multi-pass layout with binary search of adjustment, that already happens with column balancing.

Alex

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Tab Atkins Jr.
Sent: Tuesday, October 06, 2009 7:25 AM
To: www-style list
Subject: [css3-text] Suggestion for text-overflow:shrink

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 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.

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

~TJ

Received on Wednesday, 14 October 2009 23:55:12 UTC