Re: [css3-box] a width that is a little less than 'fit-content'

On Wed, Sep 16, 2009 at 5:09 AM, Bert Bos <bert@w3.org> wrote:
> On Wednesday 16 September 2009, Brad Kemper wrote:
>> I understood it to mean: Make the text box as big as you can without
>> overflowing its parent container. This determines where the text
>> wraps. Then shrink the width of the box as much as you can without
>> having to re-wrap the text.
>
> That's pretty close, I think. But do you really mean "without having to
> re-wrap" or do you mean "without the box changing height"?

I think the former (without having to re-wrap) is intended.  It's
difficult to imagine how one would explain the latter when talking
about when to use this keyword.  The former also seems much easier to
specify.

> But I gave an example with text to show where the problem lies. Text has
> a lot of flexibility. You can make it take up more or less space
> without the reader noticing. High-end systems not only stretch the
> spaces, but also shrink them. And they put the letters closer together
> if necessary, too. There is even an algorithm by Herman Zapf that
> changes the shape of the letters themselves by a tiny amount to gain
> (or lose) space for an extra letter on the line. So if the definition
> is just "lay out the content and then make it as narrow as possible,"
> you may end up with something that is much narrower than you wanted and
> looks positively ugly.
>
> You'd want something that is "optimal" within the constraints of a given
> space. But without prescribing a precise line breaking algorithm, it's
> difficult to define "optimal." (And the result will be different in
> different implementations, but that isn't a big problem.)

I'm not certain how you got to the idea of "make it as narrow as
possible".  It seems from the original problem description (and my own
idea of how this would be useful) that the idea here is just to set
the element width to the visual width of the content, however one has
specified things.  So just lay it out exactly as you would normally,
calculate the actual visible width (subtract rightmost painted pixel
from leftmost painted pixel for each line, and take the maximum), and
set the element width to that.

The only conflict now is with methods that adjust the visual width of
a line depending on the available line width, like text-align:justify
(I believe this is the only such property in vanilla CSS, but there
may be proprietary extensions that allow more capabilities, and future
official properties may be created).  One could just say that this
width ("wrap-content"?) is equivalent to fit-content in this case, but
that seems suboptimal.  When I use text-align:justify I'm not trying
to make a statement about the desired visual width of the element; I'm
just saying that *whatever* the width, I'd like all of the lines to be
the same.  So in these cases we can define the wrap-content width as
being calculated under some 'default' settings - in the case of
text-align, it would be calculated as if text-align:left had been
specified.  I'm not sure if it would be best to specify that this
should always be the default value of the offending property, or if we
should be flexible and allow ourselves to specify an explicit value
that should be assumed in this calculation for each property.  (Or, of
course, just leave any decision of what values to assume in these
cases up to the device based on what it thinks is smartest, like we do
with most text variables.)

In more precise terms, if a device makes decisions about visual width
of inline content based on the space allowed, for the purpose of this
property it should try to instead determine the width in a
'reasonable' manner which does not depend on the actual space allowed
but which otherwise changes line-breaking behavior as little as
possible, and does not change the height of the element at all.

If there is no such 'reasonable' manner, then wrap-content is
equivalent to fit-content.

~TJ

Received on Wednesday, 16 September 2009 23:11:52 UTC