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

I wrote some 19 days ago (but forgot to cc www-style
and then forgot to forward it):

> From thelawnet@yahoo.com  Wed Nov 10 10:11:43 1999
> Date: Wed, 10 Nov 1999 07:11:41 -0800 (PST)
> From: =?iso-8859-1?q?Matthew=20Brealey?=
> <thelawnet@yahoo.com>
> Subject: 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
> To: "L. David Baron" <dbaron@fas.harvard.edu>
> 
> 
> --- "L. David Baron" <dbaron@fas.harvard.edu> wrote:
> > On Wed, 10 Nov 1999 03:11:24 -0800 (PST),
> > =?iso-8859-1?q?Matthew=20Brealey?=
> > (thelawnet@yahoo.com) 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
> > does.
> The point was that the spec talks of overlapping,
> and
> describes how content is rendered in front (i.e.,
> there may be two overlapping pieces of text), and
> then
> follows it with an picture that is described as
> float
> _overlapping_ a block box, with the content
> _displaced_ (NB. not placed in front of). According
> to
> the previous paragraph, where overlap occurs,
> content
> is placed in front.
> 
> Thus the spec goes from talking of overlapping with
> one definition, to a picture that is also described
> as
> an example of overlap, with two mutually exclusive,
> incompatible definitions.
> 
> > 
> > > So what should be stated is:
> > > 
> > > HEADING: Negative borders:
> > 
> > Why do you call this negative borders?
> 
> Sorry, it was a slip, should read margins.
> 
> > 
> > > 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.
> This was slightly unclear on my part. What I should
> have written was "a float can overlap other _line_
> boxes in the normal flow"
> 
> > 
> > > HEADING: Elements overlapping preceding float
> > elements
> > 
> > Why is there a need to split this into a separate
> > case?
> Because I have made the distinction between overlap
> of
> the kind that causes displacement (normal overlap
> caused by normal float), and overlap that causes
> overlap of content (only caused by negative
> margins).
> 
> > 
> > > ------------------
> > > 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. 
> Quite how this answers the point I fail to see.
> 
> What of: 
> 
> SPAN.indiv {float: left;
> margin-top: -10px}
> DIV {}
> 
> <div>
> <span class="indiv"></span>
> </div>
> Where indiv's margin-top should (if - margin-top is
> allowed on floating elements) put it above the DIV.
> 
> > > Floated inline elements only:
> > 
> > There's no such thing as a floated inline element.
> 
> > See section 9.7
> > of CSS2 [3].
> I think I made it clear that I realised this in the
> correction of SPAN.
> 
> Although all floated elements have display: block
> automatically set on them, there is clearly a
> practical distinction between the situation where an
> inline element is floated inside a block element,
> which causes displacement of text and reflow, and
> floating of block elements, which does not.
> 
> > 
> > > 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].
> 
> You are. I think the word _change_ is key.
> 
> > I think it would be helpful if you didn't try and
> > fit so much into one
> > message (especially when the topics are
> unrelated).
> Sorry. It was just that I prefer to have one e-mail
> than 20.


=====
----------------------------------------------------------
From Matthew Brealey (http://members.tripod.co.uk/lawnet (for law)or http://members.tripod.co.uk/lawnet/WEBFRAME.HTM (for CSS))
__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one place.
Yahoo! Shopping: http://shopping.yahoo.com

Received on Monday, 29 November 1999 10:36:29 UTC