Re: [CSS21]9.5 Float

szukw000@arcor.de wrote:
> I have to make some proposals for corrections regarding the
> 
> Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification W3C
> Candidate Recommendation 23 April 2009
> 
> PROPOSAL 1:
> ===========
> 
> Comment: The change in Paragraphs 3 and 4 are based on the principle
> "first come first served". If I really WANT the floated box to be the
> first box, then I write the float first. But if I write it second (or
> later), then I WANT it to go downward so that the inline boxes can
> flow around the float.
> 
> 9.5 Floats
> 
> Paragraph 2, sentence 1:
> 
>   A floated box is shifted to the left or right until its outer edge
>   touches the content edge of the containing block or the outer edge
>   of another float.

This proposal (s/the containing block edge/the content edge of the
containing block/) is based on a misunderstanding of the definition[1]
of containing block.  The current wording is correct.


> 
> Paragraph 3:("first come first served")
> 
>   If a floated box comes after an inline box or if there is not enough
>   horizontal room for the float, it is shifted downward until either it
>   fits or there are no more floats present.
> 

With this proposal (the addition of "If a floated box comes after an
inline box or"), I presume you mean that if there are inline boxes
already on the line in which the element to be floated is encountered,
then the float should be moved to the line below rather than floated on
the same line.  This is actually what some older browsers do.  (I think
IE6/7 and Firefox2/3, off the top of my head.)

There's an interesting typographical decision to be made here:

1.) Always move the float downwards if there is prior inline content on
the line.  (Your proposal, implemented in some older browsers.)

2.) Once its width as a float has been computed (which is independent of
its position on the page), move the float downwards only if there is
prior inline content on the line and this computed width exceeds the
remaining space in the current line box.  (What the current spec seems
to want to say,[2] implemented in most newer browsers.)

3.) Once its width as a float has been computed, move the float
downwards only if only this computed width exceeds the width of the
current line box, irrespective of whether there is prior inline content
on the line. ("Keep on the same line if at all possible"; I don't recall
if this is implemented anywhere.)

I prefer (2) from a typographical point of view since it tries to keep
the float on the same line as an imaginary zero-width inline box which
marks the place in the content flow where the element to be floated was
first encountered.

With (3), the float can sometimes be higher than the "marker", whilst
with (1) the float is generally lower than the marker.

Why do you prefer (1)?  I'm guessing that one of your reasons might be
that had you wanted a left float to appear on the first line of a
paragraph you would would simply have inserted the to-be-floated element
directly before the paragraph in the document, and that by virtue of
/not/ having inserted the element there and instead inserted it "inside"
the paragraph, you're indicating that don't want it on the same line as
the first line of the paragraph.

But why, specifically, do you not like having it on the same line?  Do
you have a particular use case in mind?  (I can't think of many
occasions when I would want to float an inline-level element found in
the middle of a paragraph at all!)


> Paragraph 4:("first come first served")
> 
>   Since a float is not in the flow, non-positioned block boxes created
>   before and after the float box flow vertically as if the float did
>   not exist. However, line boxes created next to the float are
>   shortened to make room for the margin box of the float. If a
>   shortened line box is too small to contain any further content, then
>   it is shifted downward until either it fits or there are no more
>   floats present.
> 

This is exactly what the spec currently says.  I presume you intended to
propose a change?



> PROPOSAL 2:
> ===========
>
> 9.5.1 Positioning the float: the 'float' property
> 
>   1. The left outer edge of a left-floating box must align with the
>   content edge of the containing block. An analogous rule holds for
>   right-floating elements.
> 
Aside from the confusion over the definition of containing block, this
proposal (s/may not be to the left of the left edge of its containing
block/must align with the content edge of the containing block/) is
certainly not desirable.

You are suggesting changing "left floats cannot escape their containing
block leftwards" to "left floats must sit on their containing block's
left edge".  This means that two consecutive left floats could not sit
side by side, even if there were room.  Apart from this being
typographically dubious, it would break almost every web page built
using floats as "columns".


> 7. A left-floating box that has another left-floating box to its left
>   must go downward if it does not fit into the current line. (Loosely:
>   a left float may not stick out at the right edge, unless it is
>   already as far to the left as possible.) An analogous rule holds for
>   right-floating elements.

This proposal (s/may not have its right outer edge to the right of its
containing block's right edge/must go downward if it does not fit into
the current line/) is vague: it is not clear what "fit into the current
line" means.  This rule should not step on the toes of other rules (for
example rule 3, which specifies the behaviour of a left float when there
is a right float to its right).  Why do you believe the current wording
is unsuitable?



> LAST PROPOSAL:
> ==============
> 
> As far as I know, "there's" and "can't" and "isn't" are spoken
> English. They should not appear in a written specification.

Yes, this section of the spec could do with a some editorial TLC!


[1] http://www.w3.org/TR/CSS2/visudet.html#containing-block-details

[2] http://lists.w3.org/Archives/Public/www-style/2009Oct/0029.html


> winfried

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

Received on Saturday, 24 October 2009 12:59:35 UTC