Re: question on width calculation for floats and tables nested inside a div

On Jul 2, 2009, at 1:28 AM, Dirk Pranke wrote:

> Hi all,
>
> In the course of investigating a bug in WebKit, I've run across some
> ambiguity on how to render tables sized at width:100% inside a div
> that also has a float in it.
>
> That sentence is a bit hard to parse, so this is best illustrated by
> looking at the example:
> https://bugs.webkit.org/attachment.cgi?id=32157
>
> The relevant part of the CSS spec is section 9.5, paragraph 3:
>
> "The border box of a table, a block-level replaced element, or an
> element in the normal flow that establishes a new block formatting
> context (such as an element with 'overflow' other than 'visible') must
> not overlap any floats in the same block formatting context as the
> element itself. If necessary, implementations should clear the said
> element by placing it below any preceding floats, but may place it
> adjacent to such floats if there is sufficient space. They may even
> make the border box of said element narrower than defined by section
> 10.3.3. CSS2 does not define when a UA may put said element next to
> the float or by how much said element may become narrower."
>
> but how are we defining "sufficient space" The block formatting
> context or the current containing block?
>
> In my interpretation, option #1 is probably what everyone should be
> doing (but no one does). Anyone want to give reasons as to why options
> #2 or #3 make more sense?

Option #1 is clearly wrong.  width:100% is not a variable width.  It  
means use 100% of the content width of the containing block.  That  
means the table in your example is as wide as the block it is  
contained in.  It cannot shrink, since you specified a precise width  
for it.    When you see a browser treating percentages as being of  
available line width, then you are in quirks mode territory.

I think #2 and #3 are both valid interpretations.  Basically  
"sufficient space" is ambiguous, since it's not clear whether you have  
to limit yourself only to the width of the table's containing block in  
this example.

WebKit used to have code that would behave more like IE and Opera in  
your example, and we took it out at some point (possibly to match  
Firefox or because of some compatibility issue... I would have to  
check the logs).  I seem to remember that what we found is that  
designers commonly made math mistakes (often box model-related and  
thus only in WebKit/Firefox and not IE/Opera), and pushing the object  
down under the float tended to result in dramatic site  
misrenderings.    In other words if the box gets a bit wider because  
of different box models in quirks mode, then Firefox/WebKit would  
misrender badly if they matched IE/Opera.  It might be that we could  
match but only in strict mode.

dave
(hyatt@apple.com)

Received on Thursday, 2 July 2009 16:43:41 UTC