Shrink-to-fit width calculation: preferred width question
in [CSS]
|
From: Ben C on 10 Jun 2010 16:47 On 2010-06-10, GTalbot <newsgroup(a)gtalbot.org> wrote: > 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]. I think the nuance to add is just want to say the stf width is the specified width, _unless_ the specified width is auto, in which case it's min(max(preferred-min, preferred-max), available) etc. as they say [some mins and maxes may be the wrong way round in that expression, check actual spec for details]. > >> 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 Well, it's not a conformance test, because the result is not defined, since the spec does not precisely specify shrink-to-fit width. They might as well define it more precisely in a future revision though, since it's not very difficult to tell what most browsers do nor what is the most sensible thing to do. I can't see a good reason for leaving it undefined.
From: dorayme on 12 Jun 2010 00:25
In article <0893aa79-a293-420e-91f6-3b0e9570bf04(a)w31g2000yqb.googlegroups.co m>, GTalbot <newsgroup(a)gtalbot.org> wrote: > On 10 juin, 01:38, dorayme <dora...(a)optusnet.com.au> wrote: .... > > GTalbot <newsgr...(a)gtalbot.org> wrote: .... > > >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. > > .... > 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. > When I read w3.org. I go for what makes sense to me and worry about my judgement *only* if I see things not working out consistently in practice in modern browsers. That way, I assume browser makers also *more or less* have understood what I am understanding. One can go mad staring too hard at W3.org writing, I don't recommend it! In this case, I see the situation as being that detailed shrink-to-fit algorithms kick in only as a last resort, when no widths are given as guides. It is sort of a general principle: even a float *itself* ceases to be shrink-to-fit if it is given a width no matter how tiny its content. The container is blind to the details 'inside' its children, the author width given to the child acting as trigger to relieve the container of the responsibility. I see the same thing everywhere in this matter, yes, even in table cells. Sure, with table cells browsers take author widths of cell elements - <td style="width: ...";> - themselves with a grain of salt. Imagine if they took them as gospel: a big table with many cells and rows with much 'direct data cell content' not fitting in the author's specified widths! But this is not the case with table cells that have an inner DIV (to take a case close to your example) that is specified to be a certain width and that is short of what can hold the DIVs content. This is an importantly different case to where widths are authored onto the cells themselves. In a container, the stated width of a child is taken as gospel and the container is thereby relieved of the responsibility of working out the width for itself from scratch. The parent takes only responsibility to get in the stated width. Yes, I guess you *do* have to see how it is so in practice rather than from the mere words and I am not criticising your puzzlement. But there is a remarkable consistency in shrink-to-fit enaction across all the contexts that trigger it. It is not just in floats but in cases of absolutely positioned containers and yes, even table cells: <http://dorayme.netweaver.com.au/shrink_to_fit.html> Note that if we gave the table in the above a width of 100% and added an extra cell with a bit of text, narrowing the browser window demonstrates the respect browsers have for author given widths of child elements that themselves have content too big for their own boots. They blindly make the overflow unreadable. Try it. Tables are kindly things, they would not crush what they could see! They cannot see what overflows an inner div when the author, according to my way of seeing it, has in effect told them not to look. > 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. > I have the advantage of special camera and sound equipment and see and hear the chatter of the elements as they go about their work... it is the language they use... "Oy, you sure you should be jutting out like that" "Yeah, sure I'm sure, no one is telling me not to, so, hey, why not? Remember pal, individual liberty is a ..." The banter informs me, you would be surprised how chatty they are! I wish I could mass produce this equipment but it is rather bulky and hard to operate. The best I can do is give you some transcripts and snaps now and then. <g> -- dorayme |