Shrink-to-fit width calculation: preferred width question
in [CSS]
|
From: GTalbot on 9 Jun 2010 23:55 Dear fellow comp.infosystems.www.authoring.stylesheets colleagues, In this testpage http://www.gtalbot.org/BrowserBugsSection/css21testsuite/float-non-replaced-width.html I do not understand why the parent container does not include the overflowed content (about 6 "X"es) of its inner child div when evaluating the preferred width and the preferred minimum width. I've read the CSS 2.1 spec, in particular http://www.w3.org/TR/CSS21/visudet.html#float-width and I can't figure this out. regards, Gérard
From: dorayme on 10 Jun 2010 01:38 In article <b0b45494-1048-4191-8903-531f6ecdf432(a)y4g2000yqy.googlegroups.com >, GTalbot <newsgroup(a)gtalbot.org> wrote: > Dear fellow comp.infosystems.www.authoring.stylesheets colleagues, > > In this testpage > > http://www.gtalbot.org/BrowserBugsSection/css21testsuite/float-non-replaced-wi > dth.html > > I do not understand why the parent container does not include the > overflowed content (about 6 "X"es) of its inner child div when > evaluating the preferred width and the preferred minimum width. > > I've read the CSS 2.1 spec, in particular > http://www.w3.org/TR/CSS21/visudet.html#float-width > and I can't figure this out. 10.3.5 is not the nicest piece of technical writing, here is a simpler understanding: Your outer div is floated and so it will be as big as its stated content, 4em, no more. The inner div will be represented as 4em whether there are spaces between some or all the Xs or not. If things cannot wrap, they will stick out when overflow is the initial 'visible': 11.1.1 visible This value indicates that content is not clipped, i.e., it may be rendered *outside the block box*. My asterisked emphasis. So we can think of shrink to fit as covering only what is *inside* a child block box. And the given 4em settles this. ----- 10.3.5 "...calculate the preferred width by formatting the content without breaking lines other than where explicit line breaks occur," seems to me about the situation where there needs to be calculation, *not* where a width is specifically given by the author as in your example. Is this perhaps the source of your puzzlement? -- dorayme
From: Ben C on 10 Jun 2010 02:54 On 2010-06-10, GTalbot <newsgroup(a)gtalbot.org> wrote: > Dear fellow comp.infosystems.www.authoring.stylesheets colleagues, > > In this testpage > > http://www.gtalbot.org/BrowserBugsSection/css21testsuite/float-non-replaced-width.html > > I do not understand why the parent container does not include the > overflowed content (about 6 "X"es) of its inner child div when > evaluating the preferred width and the preferred minimum width. That div is explicitly 4em wide. Therefore its content minimum and content maximum widths are both also 4em, for the purposes of shrink-to-fit calculations, regardless of its actual content. > I've read the CSS 2.1 spec, in particular > http://www.w3.org/TR/CSS21/visudet.html#float-width > and I can't figure this out. Well it says there, "CSS 2.1 does not define the exact algorithm". Note that the algorithm I describe above is not exactly the same as the one used for table-cells-- for those, a minimum width is never smaller than the actual minimum width of the content, regardless of the explicit width. If a browser did show the red bit in your example, i.e. shrunk-to-fit the content regardless of the explicit width, as you were expecting, I don't think it would be wrong according to the spec. That is also what I probably would have implemented if I only had the spec and no other browsers to check in. But what browsers actually do is more useful (and not wrong because of the latitude allowed by 10.3.5): you can always leave the width of that 4em div as auto if you want the originally-expected behaviour. The rules for table-cells are different because table-cells never get overflowed. A table with a little scrollbar in every single cell is the nightmare everyone is trying to avoid. Another shrink-to-fit example to try, where I have seen differences between browsers, is something like this: <div style="float: left"> <div style="float: left; width: 100px"></div> <div style="float: right; width: 100px"></div> </div> The outer div gets 200px in most browsers, but the full available width in Firefox (at least the last time I tried it).
From: GTalbot on 10 Jun 2010 12:24 On 10 juin, 01:38, dorayme <dora...(a)optusnet.com.au> wrote: > In article > <b0b45494-1048-4191-8903-531f6ecdf...(a)y4g2000yqy.googlegroups.com > > > > >, > GTalbot <newsgr...(a)gtalbot.org> wrote: > > Dear fellow comp.infosystems.www.authoring.stylesheetscolleagues, > > > In this testpage > > >http://www.gtalbot.org/BrowserBugsSection/css21testsuite/float-non-re... > > dth.html > > > I do not understand why the parent container does not include the > > overflowed content (about 6 "X"es) of its inner child div when > > evaluating the preferred width and the preferred minimum width. > > > I've read the CSS 2.1 spec, in particular > >http://www.w3.org/TR/CSS21/visudet.html#float-width > > and I can't figure this out. > > 10.3.5 is not the nicest piece of technical writing, here is a > simpler understanding: > > Your outer div is floated and so it will be as big as its stated > content, 4em, no more. I could have said: The outer div is floated and so it will be as wide as its child content: XXXXXXXXXXX The spec says " calculate the preferred width by formatting the content without breaking lines other than where explicit line breaks occur " Child content (XXXXXXXXXXX) versus specified content width (4em) of its child. Preferred width for parent floated block should be what? specified content width (4em) of its child? or formatted child content (XXXXXXXXXXX) which obviously does not have any line breaks? Maybe I am not asking myself the correct questions. When content overflows out a box (horizontally or vertically), then where is such overflowed content rendered? I originally thought it needed to be by the parent... but in fact it is not: overflowed content of child is rendered above (z-axis) the parent, just out of, on the side of the child box content box. Non-positioned block-level elements are painted according to containment hierarchy: ancestors first, then descendants in tree order. What overflows from a dimensioned descendant should not make parent any wider or taller. > The inner div will be represented as 4em > whether there are spaces between some or all the Xs or not. If > things cannot wrap, they will stick out when overflow is the > initial 'visible': > > 11.1.1 > visible > This value indicates that content is not clipped, i.e., it may be > rendered *outside the block box*. I think the most counter-intuitive aspect of CSS 2.x is that often boxes do not behave like stretchable, elastic containers. Often, boxes do not grow because of amount of content. Overflow: visible is obviously counter-intuitive for CSS beginners. Btw, Dorayme, your floatHouse serie of article uses a bunch of interesting verbs to describe the dynamism of floated block boxes: jut out, park, spill, sidle up, etc. > My asterisked emphasis. So we can think of shrink to fit as > covering only what is *inside* a child block box. And the given > 4em settles this. > > ----- > 10.3.5 > > "...calculate the preferred width by formatting the content > without breaking lines other than where explicit line breaks > occur," > > seems to me about the situation where there needs to be > calculation, *not* where a width is specifically given by the > author as in your example. Is this perhaps the source of your > puzzlement? Yes. Calculation instead of just taking the stated content width of its sole child. Parent container has width: auto; its sole child has a specified width with too much content for such width. There is a legitimate reason to wonder at first a bit here. And also "Roughly", "not define the exact algorithm" could lead any browser to render red in that testpage. It's not *_explicitly_* clear which proposition (preferred width definition or preferred minimum width definition) has no exact algorithm. You have to interpret... How to calculate the preferred width seems to me rather clear, at least for an human: you just have to check if there are any <br> in the content. Dorayme, I appreciate the time and efforts you have given me. I have searched and read a lot about this shrink-to-fit width calculation issue. regards, Gérard
From: GTalbot on 10 Jun 2010 12:55
On 10 juin, 02:54, Ben C <spams...(a)spam.eggs> wrote: > On 2010-06-10, GTalbot <newsgr...(a)gtalbot.org> wrote: > > > Dear fellow comp.infosystems.www.authoring.stylesheetscolleagues, > > > In this testpage > > >http://www.gtalbot.org/BrowserBugsSection/css21testsuite/float-non-re... > > > I do not understand why the parent container does not include the > > overflowed content (about 6 "X"es) of its inner child div when > > evaluating the preferred width and the preferred minimum width. > > That div is explicitly 4em wide. Therefore its content minimum and > content maximum widths are both also 4em, for the purposes of > shrink-to-fit calculations, regardless of its actual content. > That's most likely what confused me in the beginning. The specified dimensions mattered, not actual content. The shrink-to-fit width calculation presumes a width: auto situation, not specified dimensions or no child with specified resolvable width value. If the child had no specified content width (like you say further down), then actual content would have mattered. > > I've read the CSS 2.1 spec, in particular > >http://www.w3.org/TR/CSS21/visudet.html#float-width > > and I can't figure this out. > > Well it says there, "CSS 2.1 does not define the exact algorithm". Note > that the algorithm I describe above is not exactly the same as the one > used for table-cells-- for those, a minimum width is never smaller than > the actual minimum width of the content, regardless of the explicit > width. > > If a browser did show the red bit in your example, i.e. shrunk-to-fit > the content regardless of the explicit width, as you were expecting, I > don't think it would be wrong according to the spec. > > That is also what I probably would have implemented if I only had the > spec and no other browsers to check in. > Then there has to be a nuance added into that section of CSS 2.1 http://www.w3.org/TR/CSS21/visudet.html#shrink-to-fit-float so that the algorithm is not used if the child[ren] of a width: auto floated parent-container all have specified dimensions resolvable [without dependencies]. > But what browsers actually do is more useful (and not wrong because of > the latitude allowed by 10.3.5): you can always leave the width of that > 4em div as auto if you want the originally-expected behaviour. Yes. > > The rules for table-cells are different because table-cells never get > overflowed. A table with a little scrollbar in every single cell is the > nightmare everyone is trying to avoid. > > Another shrink-to-fit example to try, where I have seen differences > between browsers, is something like this: > > <div style="float: left"> > <div style="float: left; width: 100px"></div> > <div style="float: right; width: 100px"></div> > </div> > > The outer div gets 200px in most browsers, but the full available width > in Firefox (at least the last time I tried it). Ben, would you like to submit that one to the CSS 2.1 test suite? I could do it for you; I could provide assistance on this. http://www.gtalbot.org/BrowserBugsSection/css21testsuite/web-authors-contributions-css21-testsuite.html regards, Gérard |