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
>> > 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
>> > 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
>> 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
> 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.
>> 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>
>> 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.
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
From: dorayme on 12 Jun 2010 00:25
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
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:
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>