Re: The dangers of inherit; the dangers of first-letter; errors in spec on float; new float rules; mistake in clear example; background-sound; @viewport

On Wed, 10 Nov 1999 03:11:24 -0800 (PST),
=?iso-8859-1?q?Matthew=20Brealey?= ( wrote:
> 4 states that this an example of floating overlapping
> borders, but according to 3, the content is rendered
> in front, i.e. on top of the float. 
> This is clearly wrong, since it should not be in front
> of the float, but next to it, as stated in 1.

This is not a contradiction.  The content is rendered in front of the
float when it is positioned at the same place as the float.  This
normally does not happen, but the spec makes allowance for when it

> So what should be stated is:
> HEADING: Negative borders:

Why do you call this negative borders?

> A float can overlap other boxes in the normal flow
> (i.e. [NB not e.g.] where a normal flow box is next to
> a float, and either have negative margins). 

No, floats overlap block boxes in all normal situations.  It's really
only the case where they overlap inline boxes that's rare.  That should
be clearer in the spec.

> HEADING: Elements overlapping preceding float elements

Why is there a need to split this into a separate case?

> ------------------
> Float rules:
> Rule 4: A floating box's outer top may not be higher
> than the top of its containg block.
> Rule 5: A floating box's outer top may not be higher
> than than the outer top of any block generated by an
> earlier element.
> Rule 6: A floating box's outer top may not be higher
> than the top of a line box that includes an earlier
> element. (NB. rule 6 is badly phrased)
> Rule 7: A left floating box to the right of another
> left floating box must not have its right outer edge
> to the right of the content edge of the block.
> These three rules seem to state that floating elements
> can't have negative top, left or right margins. If
> this is the case, it should be stated in so many
> words. 
> If not, these rules are wrong. 

The outer top is defined as the top margin edge.  See [1].

> The options are:
> 1. Allow negative margins, and resolve overlaps
> according to the HEADING: Negative borders.

> I would opt for 1.

I'm not sure what you mean here.  The only box that matters for
anything outside the float is the margin box of the float.

> In addition, I think the float rules are
> unsatisfactory. I would change them to:

I agree that they're unsatisfactory (see [2]).  However, I don't see
what your changes do (if I'm understanding correctly what you want to
change, which is not at all clear) other than make the existing rules
more vague and less formal (in the sense that a normative statement in
a spec should be).  You also seem to be trying to add the third
paragraph of CSS2 9.5 and the definition of clear into the rules for
positioning floats, which is unnecessary.

> Floated inline elements only:

There's no such thing as a floated inline element.  See section 9.7
of CSS2 [3].

> Floated block elements only:
> Rule 3: Subsequent block elements flow round the float
> as if it was part of the left (right) margin (although
> for the purposes of calculating width: auto they do
> not).
> The bracketed text in rule 3 could be omitted.
> Note that this would be an important change, because
> it means that this will work:

If I understand what you're saying correctly (which I may not), it
would not be backwards-compatible either.  See my proposal for
float-displace [2].

> The mistake in the clear example:
> At the example at 9.8.3, clear is assigned to SPAN, an
> inline element.

Good catch.  This is definitely an error in the spec.

I think it would be helpful if you didn't try and fit so much into one
message (especially when the topics are unrelated).


[2] , subsection
     entitled "Changes to float rules"  (although I think there may
	 be one post missing from that list...)

L. David Baron    Sophomore, Harvard (Physics)
Links, SatPix, CSS, etc.     <URL: >
WSP CSS AC                      <URL: >

Received on Wednesday, 10 November 1999 09:46:41 UTC