Shrink to fit

[Neville Hillyer]

This is my first post to this list so I hope you will excuse any minor protocol
infringements.

For some while I have been concerned that CSS 2.1 'shrink-to-fit' cannot be made
to work as many would wish except on a few old browsers. An outer box cannot be
made to shrink around inner boxes except in the special case of the inner boxes
all being on one line. I have produced a web page on this at:
http://links.open.ac.uk/www/shrink-wrap/

I am not proposing changes which would affect existing designs but I am
requesting an additional CSS 3 option which would invoke the performance
explained on my page. I accept that this would add a small amount of complexity
and, if imprudently implemented, may have speed implications but, nevertheless,
I think this more intuitive method is sufficiently important to warrant this.

Initial indications are that although those responsible may discuss this
proposal it is unlikely to get much further unless others join with me and
support it.

--

Neville

http://neville.hillyer.eu
       
       
       
       

[herenvardo]

On Thu, Sep 24, 2009 at 5:30 PM, Neville Hillyer <n.hillyer@...> wrote:

> This is my first post to this list so I hope you will excuse any minor
> protocol infringements.
>
> For some while I have been concerned that CSS 2.1 'shrink-to-fit' cannot be
> made to work as many would wish except on a few old browsers. An outer box
> cannot be made to shrink around inner boxes except in the special case of
> the inner boxes all being on one line. I have produced a web page on this
> at: http://links.open.ac.uk/www/shrink-wrap/
>
> I am not proposing changes which would affect existing designs but I am
> requesting an additional CSS 3 option which would invoke the performance
> explained on my page. I accept that this would add a small amount of
> complexity and, if imprudently implemented, may have speed implications but,
> nevertheless, I think this more intuitive method is sufficiently important
> to warrant this.
>
> Initial indications are that although those responsible may discuss this
> proposal it is unlikely to get much further unless others join with me and
> support it.

First of all, I'd like to make sure your proposal is what I think it
is. If I understood it correctly, the idea would be to have the yellow
box shrink further when the outer (maroon) box already forces the blue
one to a second line; but the shrink-to-fit would still never cause on
its own the content to break into more lines; am I right?
If that's what you are proposing, then I must agree 100% with having
an option for that. Looking at the FF3 example: the box does neither
shrink nor fit the contents, despite both things are what should be
expected from something called "shrink-to-fit". I can't think of any
case where FF3 behavior would be desired, but on almost all the sites
I'm working something with FF2 behavior would be a bless (actually, I
could even get rid of some <table>-based layouts).

To summarize my use-cases, they all boil down to having a sane way to
define the width for navigation side-bars without wasting screen real
state. Also I built a site last June[1] where I had to hardcode an
approximate width to center a "drop-down" menu on the screen: being
able to use shrink-to-fit instead of hardcoded widths to trigger
"margin: auto"'s block centering behavior would be a bless and would
allow sites to either look better and be more resilient, or get rid of
javascript-based re-positioning.

Just my thoughts

Regards,
Eduard Pascual

[1]http://www.abc-jitkasplayground.com/  The relevant block is the
centered menu on the home page.

[Neville Hillyer]

I am grateful for your support Eduard.

You are correct, my requested option would not normally force the blue box onto
the next line but it would cause the yellow box to follow it as in the
JavaScript version at the bottom of http://links.open.ac.uk/www/shrink-wrap/

--

Neville

http://neville.hillyer.eu

[Tab Atkins Jr.]

On Thu, Sep 24, 2009 at 10:30 AM, Neville Hillyer <n.hillyer@...> wrote:
> This is my first post to this list so I hope you will excuse any minor
> protocol infringements.
>
> For some while I have been concerned that CSS 2.1 'shrink-to-fit' cannot be
> made to work as many would wish except on a few old browsers. An outer box
> cannot be made to shrink around inner boxes except in the special case of
> the inner boxes all being on one line. I have produced a web page on this
> at: http://links.open.ac.uk/www/shrink-wrap/

Bert actually brought this up just a little bit ago:
http://lists.w3.org/Archives/Public/www-style/2009Sep/0149.html

The details about how this interacts with text and flexible space
aren't quite finalized, but the overall idea is definitely recognized
as being useful and desirable.

~TJ

[L. David Baron]

On Thursday 2009-09-24 16:30 +0100, Neville Hillyer wrote:

> For some while I have been concerned that CSS 2.1 'shrink-to-fit' cannot
> be made to work as many would wish except on a few old browsers. An outer
> box cannot be made to shrink around inner boxes except in the special
> case of the inner boxes all being on one line. I have produced a web page
> on this at: http://links.open.ac.uk/www/shrink-wrap/
>
> I am not proposing changes which would affect existing designs but I am  
> requesting an additional CSS 3 option which would invoke the performance  
> explained on my page. I accept that this would add a small amount of
> complexity and, if imprudently implemented, may have speed implications
> but, nevertheless, I think this more intuitive method is sufficiently
> important to warrant this.

I think the behavior change that led to the "a few old browsers"
data point is that there have historically been two different
approaches to implementing shrink-wrapping.

One is to use the same code that is used for layout, but run it in a
mode where it does the layout according to different rules and
computes shrink-wrap widths.  This produces better results for a
small number of cases:  a few cases involving floats, and an easy
choice to produce different results in the case you describe (it's
hard to say whether it's better or not).  However, it is also a lot
more complicated, much harder to get right, and much more likely to
lead to buggy implementations of both shrink-wrapping and handling
of dynamic changes in general.  The Firefox 2 behavior in the case
you're looking at is sort of the natural result of this approach.
Based on looking at shrink-wrapping behavior around floats, I think
this is the approach used by IE4-IE7, and by Firefox 2 and earlier.

The other is to do intrinsic width calculation using entirely
separate code using an algorithm separate from the layout
algorithms.  This is significantly easier to get right without major
bugs, but it means that it's pretty much impossible to make
intrinsic widths depend on characteristics of layout such as
placement of floats relative to text.  Based on behavior in the
presence of floats, I think this is the behavior used by Firefox 3
and later, by WebKit, and by Opera.

(I'm actually not sure what IE8 does, but I ought to look sometime.)

In this second approach, I think the implementation complexity of
what you're calling an extra "option" is actually similar to the
implementation complexity of intrinsic width calculation itself; it
requires methods for every rendering object to compute the "occupied
width" within a given width (and cache both the input and the
result).

In other words, I think it's a lot of complexity for a relatively
minor feature.  And I suspect the demand for this feature may be
alleviated by having layout systems better designed for the layouts
people are trying to design.

-David

--
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

[Alex Mogilevsky-2]

For the record, IE8 does the same thing as Firefox 3 -- shrink-to-fit size is the parent size when the parent is smaller than optimal width and bigger than actual width after float positioning.

I'll agree with David that the requested layout mode is more computationally expensive -- it pretty requires full layout for shrink-to-fit calculation, while current behavior needs to just find the longest word (it is much, much more complicated than that, but it allow for a number of optimizations).

I think however that the reason for current behavior is interoperability more than performance. Not sure if the algorithm is documented in CSS2.1, but current implementations are clearly interoperable so this behavior is not changing.

It is of course possible to implement the other behavior too, if there is a need for it. Which leads to the next question - if an option existed for a "tighter" shrink to fit, how would it be used? Is there an example where it would make a significant difference? Perhaps something that would be really hard or impossible to do with current standard?

--Alex

-----Original Message-----
From: www-style-request@... [mailto:www-style-request@...] On Behalf Of L. David Baron
Sent: Friday, September 25, 2009 5:06 PM
To: www-style@...
Subject: Re: Shrink to fit

On Thursday 2009-09-24 16:30 +0100, Neville Hillyer wrote:

> For some while I have been concerned that CSS 2.1 'shrink-to-fit'
> cannot be made to work as many would wish except on a few old
> browsers. An outer box cannot be made to shrink around inner boxes
> except in the special case of the inner boxes all being on one line. I
> have produced a web page on this at:
> http://links.open.ac.uk/www/shrink-wrap/
>
> I am not proposing changes which would affect existing designs but I
> am requesting an additional CSS 3 option which would invoke the
> performance explained on my page. I accept that this would add a small
> amount of complexity and, if imprudently implemented, may have speed
> implications but, nevertheless, I think this more intuitive method is
> sufficiently important to warrant this.

I think the behavior change that led to the "a few old browsers"
data point is that there have historically been two different approaches to implementing shrink-wrapping.

One is to use the same code that is used for layout, but run it in a mode where it does the layout according to different rules and computes shrink-wrap widths.  This produces better results for a small number of cases:  a few cases involving floats, and an easy choice to produce different results in the case you describe (it's hard to say whether it's better or not).  However, it is also a lot more complicated, much harder to get right, and much more likely to lead to buggy implementations of both shrink-wrapping and handling of dynamic changes in general.  The Firefox 2 behavior in the case you're looking at is sort of the natural result of this approach.
Based on looking at shrink-wrapping behavior around floats, I think this is the approach used by IE4-IE7, and by Firefox 2 and earlier.

The other is to do intrinsic width calculation using entirely separate code using an algorithm separate from the layout algorithms.  This is significantly easier to get right without major bugs, but it means that it's pretty much impossible to make intrinsic widths depend on characteristics of layout such as placement of floats relative to text.  Based on behavior in the presence of floats, I think this is the behavior used by Firefox 3 and later, by WebKit, and by Opera.

(I'm actually not sure what IE8 does, but I ought to look sometime.)

In this second approach, I think the implementation complexity of what you're calling an extra "option" is actually similar to the implementation complexity of intrinsic width calculation itself; it requires methods for every rendering object to compute the "occupied width" within a given width (and cache both the input and the result).

In other words, I think it's a lot of complexity for a relatively minor feature.  And I suspect the demand for this feature may be alleviated by having layout systems better designed for the layouts people are trying to design.

-David

--
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

[herenvardo]

@ David:
The link on Neville's initial proposal included a case-specific sample
implementation in Javascript, and it only takes two statements to do
the size fixing. Even in the general case, this shouldn't have too
much of a performance impact.
IMO, the sanest way to implementing this proposal would be to just
adjust the size of any relevant element when its size is changed by
any other reason (including if the element got more room after
shrinking a nearby element.
Of course, this might have a more serious performance impact on those
pages that abuse this feature (in the extreme case, applying this to
all elements); but these extreme cases would be as silly as a while(1)
doSomething; script.

@ Alex:
On Sat, Sep 26, 2009 at 2:37 AM, Alex Mogilevsky <alexmog@...> wrote:
> I think however that the reason for current behavior is interoperability more than performance. Not sure if the algorithm is documented in CSS2.1, but current implementations are clearly interoperable so this behavior is not changing.
There is no intent to alter current behavior. The proposal is about
adding some *explicit* option in CSS3 to trigger the new behavior only
on the chosen elements.
Achieving an interoperable implementation for the new feature between
different browsers should be a matter of providing clear enough spec
text and a good test suite.

> It is of course possible to implement the other behavior too, if there is a need for it. Which leads to the next question - if an option existed for a "tighter" shrink to fit, how would it be used? Is there an example where it would make a significant difference? Perhaps something that would be really hard or impossible to do with current standard?
On my first reply to this thread, I shared a link to an example that
would fall into the "impossible" (without scripting) category.
The link, again, is http://abc-jitkasplayground.com/. The relevant
part of the page is the dropdown menu below the logo. These is what
the client and artist asked for:
1) The menu should be centered. This wasn't entirely achieved: it gets
close to centered for wider viewports, but it had to use approximate
sizes to avoid breaking when a replacement font is used.
2) When the viewport is resized to be narrower than the full menu, the
menu should break into multiple lines, but it should be still be
centered (this is, the remaining h-space after sending enough elements
down to new lines should be equally split among both sides).
3) It shouldn't use javascript to solve this. Not very rational, but
go try to explain a non-expert client that javascript compatibility
issues are a ghost from the past and easily avoided with sane
scripting practices and careful fallback. At the end of the day, it's
the client who pays the bills ^^;

With a "shrink-more-to-actually-fit" feature, this could have been
done via inline blocks, absolute positioning for the submenus, and
display:none vs. display:whatever based on :hover state. Without such
a feature, it turned out to be impossible to implement. Maybe using
inline blocks instead of the floats trick could have made 1) work, but
2) is currently unachievable without script.

Regards,
Eduard Pascual

[Brad Kemper]

On Sep 26, 2009, at 2:46 AM, Eduard Pascual wrote:

The link, again, is http://abc-jitkasplayground.com/. The relevant
part of the page is the dropdown menu below the logo. These is what
the client and artist asked for:
1) The menu should be centered. This wasn't entirely achieved: it gets
close to centered for wider viewports, but it had to use approximate
sizes to avoid breaking when a replacement font is used.
2) When the viewport is resized to be narrower than the full menu, the
menu should break into multiple lines, but it should be still be
centered (this is, the remaining h-space after sending enough elements
down to new lines should be equally split among both sides).
3) It shouldn't use javascript to solve this. Not very rational, but
go try to explain a non-expert client that javascript compatibility
issues are a ghost from the past and easily avoided with sane
scripting practices and careful fallback. At the end of the day, it's
the client who pays the bills ^^;

With a "shrink-more-to-actually-fit" feature, this could have been
done via inline blocks, absolute positioning for the submenus, and
display:none vs. display:whatever based on :hover state. Without such
a feature, it turned out to be impossible to implement. Maybe using
inline blocks instead of the floats trick could have made 1) work, but
2) is currently unachievable without script.

I don't understand why this couldn't have been accomplished with inline-block elements inside a text-align:center element.

[herenvardo]

On Sat, Sep 26, 2009 at 7:38 PM, Brad Kemper <brad.kemper@...> wrote:
> I don't understand why this couldn't have been accomplished with
> inline-block elements inside a text-align:center element.

Sorry, my bad. I just have tested the "menu" thing alone and it seems
that display:inline-block + text-align:center does the job. Of course,
it breaks miserably on IE7 and earlier, which I guess was the reason I
had to mess so heavily with the code.
Since it is pointless to discuss legacy browsers' incompatibilities
here, please ignore that example and accept my apologies for the
mistake.

Regards,
Eduard Pascual

[Brad Kemper]

On Sep 26, 2009, at 1:14 PM, Eduard Pascual <herenvardo@...>  
wrote:

> On Sat, Sep 26, 2009 at 7:38 PM, Brad Kemper <brad.kemper@...>  
> wrote:
>> I don't understand why this couldn't have been accomplished with
>> inline-block elements inside a text-align:center element.
>
> Sorry, my bad. I just have tested the "menu" thing alone and it seems
> that display:inline-block + text-align:center does the job. Of course,
> it breaks miserably on IE7 and earlier, which I guess was the reason I
> had to mess so heavily with the code.
> Since it is pointless to discuss legacy browsers' incompatibilities
> here, please ignore that example and accept my apologies for the
> mistake.
>
> Regards,
> Eduard Pascual

IE6 and higher can do a good job on display:inline-block as long as  
the original HTML object was inline or inline-block to begin with. So,  
it would not work on LI elements, but a series of A elements (without  
the list structures) should work. Just an FYI.
 

[Tab Atkins Jr.]

On Sat, Sep 26, 2009 at 12:38 PM, Brad Kemper <brad.kemper@...> wrote:
> I don't understand why this couldn't have been accomplished with
> inline-block elements inside a text-align:center element.

In fact it can be, and doing so fulfills all 3 of Eduard's requirements.

~TJ

[Anton Prowse]

Brad Kemper wrote:

> On Sep 26, 2009, at 1:14 PM, Eduard Pascual <herenvardo@...> wrote:
>
>> On Sat, Sep 26, 2009 at 7:38 PM, Brad Kemper <brad.kemper@...>
>> wrote:
>>> I don't understand why this couldn't have been accomplished with
>>> inline-block elements inside a text-align:center element.
>>
>> Sorry, my bad. I just have tested the "menu" thing alone and it seems
>> that display:inline-block + text-align:center does the job. Of course,
>> it breaks miserably on IE7 and earlier, which I guess was the reason I
>> had to mess so heavily with the code.
>> Since it is pointless to discuss legacy browsers' incompatibilities
>> here, please ignore that example and accept my apologies for the
>> mistake.
>>
>> Regards,
>> Eduard Pascual
>
> IE6 and higher can do a good job on display:inline-block as long as the
> original HTML object was inline or inline-block to begin with. So, it
> would not work on LI elements, but a series of A elements (without the
> list structures) should work. Just an FYI.
>
>

Actually, it is not necessary that the original element be inline or
inline-block to begin with; just that its computed style be inline with
hasLayout.  The latter can be induced by zoom:1 if no other
hasLayout-triggering properties[1] are in use.  This inline-block
behaviour can be seen in action in an [unrelated] test case.[2; last
example]

IE7 (but not IE6) recognizes a display value called "inline-block" but
its only effect is seemingly to induce hasLayout, whilst the element
continues to use its native display value.

Hence, ironically, using display:inline-block is the one
hasLayout-inducer we /can't/ use to help achieve inline-block behaviour
on block-level elements since we must have display:inline!

(Brad's comment describes one special case: if the original element was
display:inline to begin with and is then given display:inline-block (or
hasLayout via some other means in IE6), then inline-block behaviour occurs.)

Inline-block behaviour has thus been reliably achievable in all the
commonly-supported browsers since the middle of this year, ever since
Firefox 2 (which didn't support it other than via unstable internal
properties) dropped off the radar.

[1] http://www.satzansatz.de/cssd/onhavinglayout.html#wherefrom
[2]
http://dev.moonhenge.net/css21/test-cases/tables/table-cell-slideshows.html

Cheers
Anton Prowse
http://dev.moonhenge.net

[Anton Prowse]

Anton Prowse wrote:
> IE7 (but not IE6) recognizes a display value called "inline-block" but
> its only effect is seemingly to induce hasLayout, whilst the element
> continues to use its native display value.

Correction:

IE6 behaves in exactly the same way as IE7 as regards
display:inline-block.  I have no idea why I claimed otherwise!

Cheers,
Anton Prowse
http://dev.moonhenge.net

[Neville Hillyer]

I would be grateful if somebody could say what is happening to this. Some earlier replies did not appear to be as positive as the one below.

Neville

On 25/09/2009 22:04, Tab Atkins Jr. wrote:

> On Thu, Sep 24, 2009 at 10:30 AM, Neville Hillyer <n.hillyer@...> wrote:
>> This is my first post to this list so I hope you will excuse any minor
>> protocol infringements.
>>
>> For some while I have been concerned that CSS 2.1 'shrink-to-fit' cannot be
>> made to work as many would wish except on a few old browsers. An outer box
>> cannot be made to shrink around inner boxes except in the special case of
>> the inner boxes all being on one line. I have produced a web page on this
>> at: http://links.open.ac.uk/www/shrink-wrap/
>
> Bert actually brought this up just a little bit ago:
> http://lists.w3.org/Archives/Public/www-style/2009Sep/0149.html
>
> The details about how this interacts with text and flexible space
> aren't quite finalized, but the overall idea is definitely recognized
> as being useful and desirable.
>
> ~TJ
>

[Neville Hillyer]

Bert

Is this something you could reply to?

--

Neville

http://neville.hillyer.eu
       

On 16/10/2009 14:56, Neville Hillyer wrote:

> I would be grateful if somebody could say what is happening to this.
> Some earlier replies did not appear to be as positive as the one below.
>
> Neville
>
> On 25/09/2009 22:04, Tab Atkins Jr. wrote:
>> On Thu, Sep 24, 2009 at 10:30 AM, Neville Hillyer
>> <n.hillyer@...> wrote:
>>> This is my first post to this list so I hope you will excuse any minor
>>> protocol infringements.
>>>
>>> For some while I have been concerned that CSS 2.1 'shrink-to-fit'
>>> cannot be
>>> made to work as many would wish except on a few old browsers. An
>>> outer box
>>> cannot be made to shrink around inner boxes except in the special
>>> case of
>>> the inner boxes all being on one line. I have produced a web page on
>>> this
>>> at: http://links.open.ac.uk/www/shrink-wrap/
>>
>> Bert actually brought this up just a little bit ago:
>> http://lists.w3.org/Archives/Public/www-style/2009Sep/0149.html
>>
>> The details about how this interacts with text and flexible space
>> aren't quite finalized, but the overall idea is definitely recognized
>> as being useful and desirable.
>>
>> ~TJ
>>
>
>

[Neville Hillyer]

I am new here and don't understand the process. Can anybody tell me the status
of this issue?

--

Neville

http://neville.hillyer.eu
       

On 16/10/2009 14:56, Neville Hillyer wrote:

> I would be grateful if somebody could say what is happening to this.
> Some earlier replies did not appear to be as positive as the one below.
>
> Neville
>
> On 25/09/2009 22:04, Tab Atkins Jr. wrote:
>> On Thu, Sep 24, 2009 at 10:30 AM, Neville Hillyer
>> <n.hillyer@...> wrote:
>>> This is my first post to this list so I hope you will excuse any minor
>>> protocol infringements.
>>>
>>> For some while I have been concerned that CSS 2.1 'shrink-to-fit'
>>> cannot be
>>> made to work as many would wish except on a few old browsers. An
>>> outer box
>>> cannot be made to shrink around inner boxes except in the special
>>> case of
>>> the inner boxes all being on one line. I have produced a web page on
>>> this
>>> at: http://links.open.ac.uk/www/shrink-wrap/
>>
>> Bert actually brought this up just a little bit ago:
>> http://lists.w3.org/Archives/Public/www-style/2009Sep/0149.html
>>
>> The details about how this interacts with text and flexible space
>> aren't quite finalized, but the overall idea is definitely recognized
>> as being useful and desirable.
>>
>> ~TJ

[François REMY]

There isn't a true process here. The mailing list is for discussion purpose
only, if I correctly understood.

I don't know if a CSS Issue has been filled with your proposal. If yes, you
should have a look at this issue to know what's the current status of your
proposal. If not, you may want to ask an implementor to fill an issue or to
say you what is the avancement on this problem, if any.

--------------------------------------------------
From: "Neville Hillyer" <n.hillyer@...>
Sent: Tuesday, October 27, 2009 3:58 PM
To: <www-style@...>
Subject: Re: Shrink to fit - anybody !!

> I am new here and don't understand the process. Can anybody tell me the
> status of this issue?
>
> --
>
> Neville
>
> http://neville.hillyer.eu
>
>
> On 16/10/2009 14:56, Neville Hillyer wrote:
>> I would be grateful if somebody could say what is happening to this. Some
>> earlier replies did not appear to be as positive as the one below.
>>
>> Neville
>>
>> On 25/09/2009 22:04, Tab Atkins Jr. wrote:
>>> On Thu, Sep 24, 2009 at 10:30 AM, Neville Hillyer <n.hillyer@...>
>>> wrote:
>>>> This is my first post to this list so I hope you will excuse any minor
>>>> protocol infringements.
>>>>
>>>> For some while I have been concerned that CSS 2.1 'shrink-to-fit'
>>>> cannot be
>>>> made to work as many would wish except on a few old browsers. An outer
>>>> box
>>>> cannot be made to shrink around inner boxes except in the special case
>>>> of
>>>> the inner boxes all being on one line. I have produced a web page on
>>>> this
>>>> at: http://links.open.ac.uk/www/shrink-wrap/
>>>
>>> Bert actually brought this up just a little bit ago:
>>> http://lists.w3.org/Archives/Public/www-style/2009Sep/0149.html
>>>
>>> The details about how this interacts with text and flexible space
>>> aren't quite finalized, but the overall idea is definitely recognized
>>> as being useful and desirable.
>>>
>>> ~TJ
>