Re: Do overlapping statically positioned elements "obscure" each other

On Thu, 16 Sep 1999 07:49:14 -0700, "Tantek Celik"
(tantek@cs.stanford.edu) wrote:
> 
> > Reading section 9.9 (although much of it only applies to positioned
> > elements) might give the impression that the box (background and
> > border) should be drawn on top of the inline content of the previous
> > box, since it says "Boxes with the same stack level in a stacking
> > context are stacked bottom-to-top according to document tree order." [1]
> 
> Yes.  This is the general rule, and then specific exceptions apply.
> 
> > However, this must be wrong because of section 9.5,
> 
> I think that is too strong of a conclusion to make - floats are simply one
> exception to that rule.
> 
> > which says:
> >
> >   A float can overlap other boxes in the normal flow (e.g., when a
> >   normal flow box next to a float has negative margins).  When an
> >   inline box overlaps with a float, the content, background, and
> >   borders of the inline box are rendered in front of the float. When a
> >   block box overlaps, the background and borders of the block box are
> >   rendered behind the float and are only be visible where the box is
> >   transparent. The content of the block box is rendered in front of the
> >   float. [2]
> 
> I believe that this text was meant to address float boxes which are adjacent
> to or children of block boxes which they are overlapping (hence the "e.g.,
> when a normal flow box *next to* a float has negative margins), and was not
> meant to make sure that a float box at the very beginning of the document is
> rendered on top of a block box at the very end of a document that has super
> high negative margin-top.

It was clearly meant to address such things as shown in the middle
figure in 9.5 [1].  Take that figure, and give the second paragraph a
negative top margin and a negative text indent.  It seems clear that
the text of the second paragraph should be on top of the float (as
described in the section), and the background of that paragraph must be
behind the float.  Yet the text of the first paragraph, if it somehow
overlaps the float, should also be in front of the float.  Since the
text of the first paragraph must be in front of the float while the
background of the second paragraph must be behind it, the text of the
first paragraph must be in front of the background of the second.

I made a simple example of this [2] and also took a screenshot of
Mozilla's rendering, which I think is largely correct [3] (ignore
the position of the HR element).

> I don't think this is what the spec intended or what authors expect, so if
> you really think that this can be concluded by your reasoning, we should
> probably errata the spec to be more clear that that was *not* what was
> intended.

I think the spec should be consistent.  I wanted to see later paragraphs
completely overlap previous ones, but after seeing what that would do
to floats I changed my mind.  Either the special rules for floats must go
(or be limited to only certain float/block pairs) or the ability of one
block to overwrite another must be sacrificed.

This is also important for event handling, I think.  Although the DOM2
hasn't really specified to which elements events go (I think it should
do so by describing how events relate to the CSS box model), I think
they should generally go to the (visible) element highest in the
stacking order.  If that doesn't happen, then pages like [4] will have
unclickable links because the blocks with negative margins steal the
events from the links.

David

[1] http://www.w3.org/TR/REC-CSS2/images/float2p.gif
[2] http://www.fas.harvard.edu/~dbaron/css/1999/09/float-layer
[3] http://www.fas.harvard.edu/~dbaron/css/1999/09/float-layer-mozilla
[4] http://www.w3.org/Style/

L. David Baron    Sophomore, Harvard (Physics)    dbaron@fas.harvard.edu
Links, SatPix, CSS, etc.     <URL: http://www.fas.harvard.edu/~dbaron/ >
WSP CSS AC                      <URL: http://www.webstandards.org/css/ >

Received on Thursday, 16 September 1999 11:18:35 UTC