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

On Thu, 16 Sep 1999, L. David Baron wrote:

> 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.
> 

If we change the example to inline elements we run into a similar
given:
  <div> .... <inline1> ... </inline1> ...
     <inline2> ... </inline2> ...
  </div>

and if we give these elements padding space such that they overlap
when rendered, then we'd expect any inline backgrounds to be under
the rendered text, as in

   bg.div < bg.inline1 < bg.inline2 < inline[1,2].content

Consistency (a.k.a. simplicity) would argue for the same ordering
when elements are 'backed' up on top of teach other.

However, returning to block element overlaps -- how should the overflow
property affect this?  We are implicitly considering overflow: visible,
but if we use overflow: hidden, should this clip just the content,
or also the background? Intuitiion says both - but I've learned that
intuition can be a dangerous thing ....

I put together a small test document that exercises the various
overflow possibilities -- at 
http://www.java.utoronto.ca/CSS-tests/overflow-test.html

This looks at the case of two subsequent block elements, the latter backed
up on top of the former. The page exercises the different overflow
property values applies to either the first paragrpah or the second
one (seven cases are illustrated) Mozilla does some weird things --
but then, I'm not sure what it _should_ do.

Ian
--
Ian Graham ......................... Centre for Academic Technology
i a n   d o t   g r a h a m    a t    u t o r o n t o   d o t   c a
..................... http://www.utoronto.ca/ian/ .................

Received on Thursday, 16 September 1999 12:25:38 UTC