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

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

> Since a float can overlap multiple blocks (which could overlap each
> other), and the inline content of both those blocks must be above the
> float while the blocks themselves (background and border) must be
> below the float.  This means that the markup:
>
> <block1>
>  <inline1/>
> </block1>
> <block2>
>  <inline2/>
> </block2>
>
> Must yield the stacking order:
>
> (BOTTOM) block1 < block2 < inline1 < inline2 (TOP, i.e., closest to user)

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.

> since if a float were present, the stacking order would be
>
> (BOTTOM) block1 < block2 < float < inline1 < inline2 (TOP)
>
> Note that the distinction between box and content is really a
> distinction between block-level and inline-level elements.  A block
> could have block-level content, in which case the block boxes (and,
> later, their inline content) should probably be painted in "start-tag
> order".

Oh, it's worse than that.  Now apply a text-decoration to all the elements
involved (different ones so they can "overlap").  Where is the
text-decoration drawn with respect to implicit stacking order?
Where *should* it be drawn (e.g. what would authors expect or want it to
do)? A rhetorical question - I think the text-decoration for a block is
drawn *after* its inline content, so that you can for example use

P.cut {text-decoration:line-through}

to strike out all inline content inside paragraphs that have been cut.

Tantek

Received on Thursday, 16 September 1999 10:50:37 UTC