W3C home > Mailing lists > Public > www-style@w3.org > October 1996

Re: margins on floated elements

From: Bert Bos <bbos@mygale.inria.fr>
Date: Fri, 25 Oct 1996 22:28:18 +0200 (MET DST)
Message-Id: <199610252028.WAA25581@mygale.inria.fr>
To: "David Perrell" <davidp@earthlink.net>
Cc: "Style" <www-style@w3.org>
David Perrell writes:
 > Bert Bos wrote:
 > > We should probably make it explicit which overlaps which. In the
 > > absence of explicit z-ordering, the best strategy is probably that
 > > non-floating things overlap floating things and that things later in
 > > the logical (document) order overlap earlier things.
 > That makes sense inasmuch as the most common use of overlap will be
 > text over images or floated first letters. But "float overlaps parent
 > except that text is always on top" also makes sense and makes it clear
 > that the floated element overlaps the background of the parent element
 > -- which I believe most author/designers would find desirable.

Agreed. We'll need a very good technical writer to explain all this
(`a float is above its parent's background, but below its parents text
and child elements'). But it makes sense. It is often the most natural
things that are hardest to describe.

 > > The effect of setting the width of a floating element (other than an
 > > image) to `auto' is currently not defined.
 > > 
 > > If we decided to define it, what would be the most useful
 > > interpretation? When I implemented this myself, I arbitrarily used
 > 1/3
 > > of the parent's width. But a more sophisticated sizing algortihm is
 > > possible as well, a la the table sizing. Requiring that would put
 > some
 > > burden on the implementations, but it may be worth it; it may give us
 > > something very close to run-in headings for free...
 > IMO, auto width of floated text should be the lesser of (the width of
 > the text) and (the width of the parent less any margins, borders and
 > padding on the float). If the lesser is the latter, the text should
 > break to multiple lines. This makes run-in headings easy if the heading
 > is one line. Left-float a first letter with appropriate font size and
 > margins and you've got a drop cap.


 > Is this really such a burden? Routines for computing the width of a
 > line of text are already there.

It can become complicated if the float has child elements itself:

        DIV.sidenote {float: left; width: auto /* =default */}
        DIV.sidenote P {margin-left: 15%}
    <div class=sidenote>
      <p>This is in a sidenote.</p>
      <p>So is this.</p>

What would be the left margin of the P?

 > In the case of elements with a width wider than the parent (either auto
 > or explicit), the additional width should extend beyond the edge of the
 > parent in the direction away from the float.

You said the float's width would be the minimum of its own content and
its parent's, how then can it be wider than its parent?

I'm not sure what you mean by `away from the float'. For the case that
a float has an explicit width that is wider than the parent, this is
how it is currently defined: a left floating element will be put
against the left margin and if it is very wide, it will extend beyond
the right edge; a right floating element will have its right edge
against the right margin, and may stick out on the left.

 > A "float-lines" property -- where the edge of the floated text element
 > corresponds to the line-box on a line-by-line basis -- would allow for
 > multi-line run-in headings. The bounding shape for a float-lines text
 > element would look like the background as applied to block text
 > elements in IE 3.0 and 3.01.

It suffers from the same problem as the example above.

But this is interesting. It is not correct yet, but it might lead us

  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/pub/WWW/People/Bos/                      INRIA/W3C
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 93 65 77 71                 06902 Sophia Antipolis Cedex, France
Received on Friday, 25 October 1996 16:28:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:41 UTC