Re: Issue 101 Resolution

On 25/10/2010 02:40, Peter Moulder wrote:
> On Wed, Oct 20, 2010 at 11:19:57AM -0700, Tab Atkins Jr. wrote:
>
>> New rule 3 text (I overcorrected for "outer edge"):
>> | 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 to the right of it and
>                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> This retains the issue that "box to the right of it" is unclear (to the
> point that Anton Prowse and I differed in our interpretations).
>
> I don't object to leaving that for a separate issue, but it's certainly
> something that needs to be defined precisely given that there are multiple
> reasonable interpretations, and the most obvious implementation wouldn't
> have the behaviour I think we want for negative-height floats.

I'm still not too clear what your interpretation of "to the right/left 
of" is.

For me (I think!), float A is to the right of float B if there exists a 
horizontal line H which satisfies both of
 a) H is below the outer top edge of both A and B
 b) H is above the outer bottom edge of both A and B
and if there exists a vertical line V which satisfies both of
 a) V intersects the margin box of B
 c) V is to the right of the outer right edge of A
(all comparisons being strict).

[Note that this intentionally excludes zero- or negative-height floats 
from ever being considered to be "to the right/left" of another float, 
in line with the parallel proposal for Issue 185.[1]]

What's your interpretation, and how does it handle negative-height floats?


>> | whose left outer edge is to the left of the
>> | left-floating box's containing block's right edge.
>
> A number of the float-related rules use phrases like "must be below" or "must
> be to the right of" when they actually (presumably) mean "... or level with".

Quite possibly (I haven't checked carefully).  Note that the "or 
incident with" interpretation of Tab's proposed wording you just quoted 
results in Gecko's behaviour not conforming, as can be seen in [2] by 
changing the margin-right of div.inner to 56px; so I'm assuming that's 
not the correct interpretation in this particular proposal.  In other 
words, the right float has to non-trivially enter the left float's 
containing block before the rule takes effect.

> Thus, there are reasonable grounds for considering "to the left of" to be
> ambiguous as to whether it includes the equality case, particularly for what
> still seems a somewhat arbitrary rule (not exactly matching "place it
> anywhere that doesn't overlap" whether we interpret it as<  or ≤), so
> I suggest clarifying one way or another: e.g. if it really means to the
> left of then prepend "(strictly)", otherwise I think "not to the right of"
> is just about good enough that a reader would be confident enough that it
> really means it.

Personally, I think the normal interpretation of "to the right of" is 
"strictly to the right of", and that only those cases where equality is 
permitted should be edited to express this more clearly.


> Have we tested implementation behaviour for the case where the left-floating
> box is wider than its containing block?  The proposed change as currently
> written would allow that left float to overlap right floats in some cases.

That's precisely the test case [2] that inspired this issue, no?  The 
left float can indeed overlap the right float in some cases.  I'm still 
in two minds about this.  I do dislike that the floats can overlap but 
the line boxes can't, and I illustrated in [3]

> (I was delaying sending this message so that I could check implementations,
> but I'm still a bit busy with other things; and from the little I did test,
> I got the impression that the proposed rule doesn't exactly match what all
> implementations are doing anyway.)

How so?


[1] http://lists.w3.org/Archives/Public/www-style/2010Sep/0130.html
[2] http://dbaron.org/css/test/2009/float-outside-tests/rule-3-left
[3] http://lists.w3.org/Archives/Public/www-style/2010Oct/0437.html

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

Received on Tuesday, 26 October 2010 18:20:49 UTC