Re: [CSS21] Issue 192 - floats and shortened line boxes

On Wednesday 2010-09-01 21:19 +0200, Anton Prowse wrote:
> From the f2f minutes[1]:
> 
> ><glazou> http://lists.w3.org/Archives/Public/www-style/2009Oct/0027.html

> >  RESOLVED: Accept change for first issue, accept dbarons' change for
> >            the second issue, third issue is invalid.
> 
> I don't believe the third issue to be invalid, and I went into
> rather a lot of detail in a later post[2] in the cited thread, in
> addition to responding[3,4] to the purported counter-example that
> Bert raised[5]. If Bert has a counter-example that he has not posted
> to the list, please could he do so.

So I think the third issue is certainly not ideal wording in the
spec.  However, I think the case you're worried about (which it
describes) is a case that other statements in the spec explicitly
prevent from ever happening.

In particular, the rules for positioning floats in 9.5 say:
  # 6. The outer top of an element's floating box may not be higher
  #    than the top of any line-box containing a box generated by an
  #    element earlier in the source document. 

  # 8. A floating box must be placed as high as possible. 

(I'd note that we all interpret "element" in rule 6 to mean "element
or part of element"... it would probably be good to make that a
little clearer so it's clear how it applies to text.)

Any layout that wraps content prior to the float, initially placed
in the line box whose top is even with the top of the float, to a
line after the top of the float, would violate rule (6).  Thus this
layout is not allowed.  Therefore rule (8) ("must be placed as high
as possible") is satisfied by placing the float even with the line
*below* its "anchor point", since placement with the higher line is
not possible since such a layout would violate rule (6).  In other
words, the layout of:
  <p>This is some text with <float>FLOAT</float> a float.</p>
as:
  | This is some text with a |
  | [FLOAT] float.           |
is correct.

So while the spec is unclear here, I don't think there is a bug or
disagreement with implementations.  And I don't think your proposed
s/first available/same/ really helps explain this situation much.
Maybe a more substantive rewrite in errata would help.

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

Received on Wednesday, 16 March 2011 16:35:55 UTC