Re: [CSS21] Nested floats and zero-height margin box

On 25/02/2012 21:45, "Gérard Talbot" wrote:
> Le Mar 21 février 2012 22:25, "Gérard Talbot" a écrit :
>> Le Mar 21 février 2012 12:45, Øyvind Stenhaug a écrit :
>>> On Sat, 18 Feb 2012 04:11:10 +0100, Gérard Talbot  <www-style@gtalbot.org> wrote:
>>>> Le Ven 17 février 2012 14:56, "Gérard Talbot" a écrit :
>>>>> I am working on the following tests:
>>>>>
>>>>> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/float-non-replaced-width-013.html
>>>>>
>>>>> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/float-non-replaced-width-014.html
>>>>>
>>>>> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/float-non-replaced-width-015.html
>>>>>
>>>>> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/float-non-replaced-width-016.html
>>>>>
>>>>> 1- Are those tests correct? If no, please explain a bit,
>>>>> preferably by quoting the relevant chunks of the spec.
>>>>
>>>> A float establishes a new block formatting context for its
>>>> children (as stated in section 9.4.1). And the right outer edge
>>>> of a left-floating box may not be to the right of the left
>>>> outer edge of any right-floating box that is next to it.
>>>> Analogous rules hold for right-floating elements. So, the
>>>> parent float should be as wide as the sum of the width of its
>>>> children.
>>>>
>>>> Consider this issue as SOLVED
>>>
>>> I don't think the spec covers these adequately.
>>>
>>> First of all, the outermost floats here are all auto-width, in
>>> which case "CSS 2.1 does not define the exact algorithm" for
>>> finding preferred width and preferred minimum width.
>>>
>>> Second of all, what does it mean for a right-floating box to be
>>> "next to" a left-floating box? This doesn't seem to be properly
>>> defined. Perhaps it should be similar to the case of lineboxes
>>> "next to" floats, where floats with zero outer height are not
>>> supposed to shorten lineboxes. Then, for e.g.
>>> float-non-replaced-width-014 it would be perfectly fine to put
>>> #floated-left-child in the top left and #floated-right-child
>>> "below" it - #floated-right-child would still be "as high as
>>> possible".
>>
>> I removed the 4 tests from the test suite (from my submitted
>> folder) until the spec "establishes" exactly the issue with those
>> tests; they are now in my /incoming folder.
>>
>> changeset 2757:9f4e2c20fd60
>> changeset 2758:efa7989c291a
>
> I filed
>
> Bug 16119: [9.5.1 Floats] How nested floats with one zero-height
> margin box should be rendered
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16119

I don't think there is a spec issue as concerns these particular tests. 
  I agree with Øyvind that it would be equally reasonable to have 
#floated-right-child "below" #floated-left-child and the parent float be 
100px wide.  However, this freedom stems from the fact that the 
outermost floats here are all auto-width, and so "CSS 2.1 does not 
define the exact algorithm" for finding preferred width and preferred 
minimum width.

If a UA chooses a 100px-wide rendering, then it cannot be regarding the 
two inner floats as being next to each other.  If a UA chooses a 
200px-wide rendering, then it's *probably* because it's regarding the 
two inner floats as being next to each other (else why not choose the 
100px-wide rendering instead) but we can only guess at the reason since 
the UA is permitted to do what it likes.  But defining "next to" more 
clearly doesn't actually help since it still wouldn't remove the freedom 
that a UA has due to the 'auto' width.

(In fact, I think a 100px-wide rendering would be more reasonable here, 
and more in keeping with the "line boxes next to floats" thing.  At 
least some UAs do a 200px-wide rendering though, which is what Gérard's 
tests assume is correct.)

If we don't like the fact that the rendering is left undefined for these 
test cases, then I think that should be fixed in CSS3 by defining the 
shrink-to-fit algorithm for floats.  As I say, defining "next to" won't 
suddenly make these tests unambiguous.

Perhaps there exist test cases which more clearly demonstrate a problem 
with the lack of explicit definition of "next to".  I can't immediately 
think of any, though, and until some arise I propose closing this bug as 
wontfix.

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

Received on Monday, 21 May 2012 10:34:47 UTC