W3C home > Mailing lists > Public > www-style@w3.org > August 2002

Re: Float overflowing behavior

From: Coises <Randy@Coises.com>
Date: Wed, 14 Aug 2002 16:33:10 -0700
To: www-style@w3.org
Message-ID: <uofllu8g85q1rjvudu078tbi1preqckir7@4ax.com>

[Wed, 14 Aug 2002 22:28:16 +0200] C. Bottelier:
>We have three cases.

I'd like to add a fourth.

Suppose I have a document like this (view in fixed pitch):

                    The document consists of text which line-wraps and is
 +---------------+  organized normally in paragraphs; but it contains a
 |term: a word   |  *term* that is to be explained further in the left 
 |we need to     |  margin.  Now, the whole idea of this kind of layout
 |explain        |  is that the needed reference (it could be a picture,
 +---------------+  a definition, any sort of thing) is right at hand
                    near the text, without actually breaking up the text.
                    To work --- since we don't know just where the text
                    will wrap --- the reference material must be included
 +---------------+  in the source text right after the word or phrase
 |boldface: a    |  (shown here in *boldface*) to allow for the correct
 |dark or thick  |  vertical alignment(in this example, the baseline of
 |type style     |  the first line box of the sidebar data is aligned with
 +---------------+  the line box that contains the word or phrase with
                    which it is the reference data is associated).

                    While the above examples are contained in the margin,
 +-------------------------+ there might also be another reference to a
 |*************************| *picture*; which might be wider than the
 |*************************| margins, so that the text would have to flow 
 |*************************| around it.  None of this is particularly 
 +-------------------------+ unusual layout; and --- at least to me ---
                    it seems very much like the concept of a "float";
                    yet, as far as I can tell, neither the float model,
                    nor anything else in CSS, could be used in an intuitive
                    way to generate this presentation.


What I draw from these examples (others' and mine) is that a "float" (as
one would think of it intuitively for layout purposes) has both a position
in the flow and a container --- the unusual things about a float are that:

1. The horizontal or the vertical  position (though not the latter in CSS2)
of a float is shifted from its "natural" place in the flow to one edge of
the container; or, in paged media, the nearer of the appropriate edge of
the container and the appropriate edge of the working area of the page.

2. The container for the float is not necessarily formed by the content
edges of the nearest block-level ancestor: for each edge, *any* block-level
ancestor may be chosen to define that boundary of the container.
Appropriate "auto" dimensions of a container should expand to contain the
float just as if the float were in normal flow; likewise, "overflow"
properties of the container should apply if dimensions are constrained.

3. The vertical position of a left or right float is determined by the
position at which it is created, and the "vertical-align" property should
apply to left and right floats.  The horizontal position of a top or bottom
float should be determined by property or value similar to the text-align
property; however, this property would align the box, not the text in it.



Viewed in terms of this model, CSS2 sets the left and right boundaries of
the container to the left and right content edges of the immediately
containing block; the bottom is effectively unbounded (and
the top really doesn't matter).  I believe CSS2 floats behave as if they
specified "vertical-align: top" in this model.



Following is a sketch of how one might represent such a model.
(This is only a sketch... many details are not addressed here.)

  Name: float
  Value: [top | bottom]? [left | right | center] | none | inherit
  Initial: none
  Applies to: block-level, non-replaced elements
  Inherited: no
  Media: visual

The box floats to the indicated position within the bounding box for the
float (see the "float-bounds" property).  If neither "top" nor "bottom" is
specified, the vertical position is determined by the position of the line
box (or containing block, if there is no line box) in which an inline
element of zero height and zero width at the same location in the source
would have been generated, and the "vertical-align" property of the float.
The height of the line box is not affected by the presence of the float.


  Name: float-bounds
  Value: [ <selector> | none ] {1,4}
  Initial: none *
  Applies to: block-level, non-replaced elements with float other than none
  Inherited: no
  Media: visual

The values of this property specify the elements whose content edges form
the top, right, bottom and left boundaries of the container for the float.

<selector>

The boundary is formed by the appropriate content edge of the nearest
ancestor of the floated element which matches the selector.  (If no
ancestor matches the selector, "none" is used.)

none

No boundary is specified for the relevant edge of the container of the
float.  (If this is specified for a boundary to which the element floats,
the parent is used for a left or right boundary; the root element is used
for a top or bottom boundary.)


Precise rules regarding the effect of a float on its container's boundaries
when they are not independently determined would need to be set down.  The
idea should be that the elements which provide the boundaries expand as
needed to contain the float, but no more than needed.



Now...

>The article based case:
>
>>This is the start of some article in the
>>magazine.
>>In this article, we have a picture, perhaps of
>>+-------------+ the author, or the subject of
>>|             | the article, or even an ad.
>>|   picture   |
>>|             | This is the second paragraph,
>>|             | which is also intended to flow
>>+-------------+ around the same picture in the
>>article.  This would be a case in which the
>>current float behavior is useful.
>
>For this case we would see some HTML like:
>
><h1 class="title">Article title</h1>
><p>Some text<img>Some text</p>
><p>Soe text</p>
>
>We would want the <img> to float left and
>the <p> elements to flow around it.

Just:
     img {float: left}
should handle this (as it does in CSS2).



>And the short definition (list) kind case:
>
>This is some introductory text.
>In this collection, we have a picture of
>+-------------+ a product with a small
>|             | introductory text that
>|   picture   | links to a page containing
>|             | its fulldescription.
>|             |
>+-------------+
>
>After both the text and the picture the
>+-------------+ next prodcut, or object
>|             | is presented. As seen in
>|   picture   | this example The previous
>|             | picture does not obscure
>|             | this picture. If the text
>+-------------+ would be large enough --
>that is the height of the C.B. of the
>paragraph equals or is more than the
>heright of the picture -- there wouldn't
>be a problem.
>
>
>For this case we would see dome HTML like:
>
><div class="product">
>   <h2 class="producttitle">Product name</h2>
>   <p>Some text<img class="productimage">Some text</p>
></div>
><div class="product">
>   <h2 class="producttitle">Product name</h2>
>   <p>Some text<img class="productimage">Some text</p>
></div>
>
>
>Where we want the <img> to float left the <p> to flow
>around the <img> and the next <div> to come below thr
><img>.

This would be handled by specifying:
     img.productimage {float: left; float-bounds: div.product}



>And the long definition (list) kind case:
>
>This is some introductory text.
>In this collection, we have a picture
>+-------------+ perhaps of a product.
>|             | It contains a full text
>|   picture   | describing it.
>|             |
>|             | To be able to do this
>+-------------+ more then 1 paraghrap
>is needed to describe it. In this case
>we don't want this behaviour.
>
>But since not all of the items described
>+-------------+ need a lot of explanation
>|             | some of the items only
>|   picture   | have 1 paraghraph. And we
>|             | don't want these pictures
>|             | to obscure the next.
>+-------------+
>
>For this kind of material we need a mixture
>+-------------+ of them both. But we still
>|             | want to describe it
>|   picture   | semantically. we need some
>|             | construction to do this.
>|             |
>+-------------+
>
>The third case is the hardest since it
>would break semantics a bit if we would
>code the picture with 1 paraghraph
>differently from the ones containing more
>than 1 paragraph.
>
>The HTML structure for the third case
>could be:
>
><h1 class="pagetitle">Product catalog</h1>
><div class="product">
>   <h2 class="producttitle">Product name</h2>
>   <p><img class="productimage">Some text</p>
>   <p>Some other text</p>
></div>
><div class="product">
>   <h2 class="producttitle">Product name</h2>
>   <p><img class="productimage">Some text</p>
></div>
>
>Here we would want the <img> to float left and
>have the <p> elemnts flow around the <img> but
>have the next <div> to come below the floating
><img> element.

This would also be handled by specifying:
     img.productimage {float: left; float-bounds: div.product}



My example would be handled with something like this:

     P.text      {margin-left: 20em}
     *.sidebar   {margin-right: 1em; border 1px solid black;
                  float: left; float-bounds: BODY}
     P.sidebar   {width: 17em; padding .5em; border: 2px solid black;
                  vertical-align: baseline}
     IMG.sidebar {vertical-align: top}

(though I am a little confused about whether "vertical-align: top" aligns
the content edge or the outer edge with the top of the line box --- it
seems one should have a choice).
-- 
Randall Joseph Fellmy aka Randy@Coises.com
Received on Wednesday, 14 August 2002 19:33:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:15 GMT