[CSS21]9.5 Float

View: New views
3 Messages — Rating Filter:   Alert me  

[CSS21]9.5 Float

by szukw000 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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.

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.

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.

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.

    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.

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.

winfried


Der E-Mail-Dienst PIA basic belegt im Test der Stiftung Warentest unter den kostenfreien Angeboten mit dem Qualitätsurteil 3,0  den zweiten Platz!
(Testheft Juli 2009, Artikel "E-Mail-Dienste - Besser gratis")
JETZT TESTEN: www.arcor.de/rd/pia_sw


Re: [CSS21]9.5 Float

by Zack Weinberg-6 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

szukw000@... 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

No comment on anything else, but ...

> 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.

... this is not true.  Contractions are perfectly fine in formal
written English.  "There's" is more informal than the contractions
involving "not", but still fine.  *Avoiding* contractions in writing
makes the text sound stilted, sometimes to the point of disfluency.

Neither should one mechanically contract everything that *can* be
contracted -- authors may choose one possible form over another to make
the text flow more smoothly, or to express a subtle shade of meaning.
For instance, if I had written "this isn't true" above the emphasis
would have been wrong.

zw


Re: [CSS21]9.5 Float

by Anton Prowse :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

szukw000@... 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