Re: [css, bug of specification] negative margins, painting order, stacking context.

Andrew Fedoniouk wrote:
> 
> Anton Prowse wrote here:
> http://lists.w3.org/Archives/Public/www-style/2009Feb/0276.html
> [I've reduced the message as it became fairly big]
> 
> Consider these two rendering schema of rendering content of some container:
> 
> (I am considering statics and floats only for brevity)
> 
> A) Current one that is in the spec. now:
> 
> 1) Draw backgrounds of all children.
> 2) Draw all floats (each float establish it own stacking context).
> 3) Draw text, inlines and inline-blocks of static elements on top of all 
> that. Inline, and inline-block elements also establish
> their own stacking context.
> 
> And another one that I was talking about,
> B) elements are rendered as if each of them establish their
> own stacking context:
> 
> 1) Draw all children atomically (background and content on top
> of it) - thus each child establish it own stacking context.
> 2) Draw all floats atomically - as in current spec.
> 
> Let's put aside negative margins feature for a while.


Sorry for the length of this reply, but I really think that it's worth
clarifying the terminology here so that we can understand each other.  A
"stacking context" is more than just an atomically-painted
background+text unit.

There are two kinds of stacking context.  The first, let's call it a
"painting context" or "pseudo--stacking context" is (loosely) an
atomically-painted unit of backgrounds, floated non-positioned
dependents and inlines. Many things form painting contexts: the root
element, floats, inline blocks, inline tables, and positioned elements.
On the other hand, many things don't: static in-flow blocks and
inlines for example.

The second kind, what I call a true "stacking context", is formed only
by the root element and positioned elements having a computed value of
'z-index' other than 'auto' (and hence these true stacking contexts are
a subset of painting contexts).  They are (loosely) an atomic unit of
backgrounds, non-positioned floats, inlines /and positioned elements/.

Why two different kinds?  Well, a positioned element participates in the
closest ancestor stacking context, while all other boxes participate in
the closest ancestor painting context.  This allows for nice subtleties
in the layout of complex designs where many things overlap:  we see that
painting contexts can contain further painting contexts, and each box
apart from the root element belongs to precisely one painting context; 
yet this containment ("the painting tree") does not necessarily 
correspond directly to the document tree because positioned elements are
not dependent upon their closest ancestor painting context but rather
upon their closest ancestor stacking context.

Now, painting contexts take responsibility for painting their dependants
("descendants" in the sloppy language of 9.9.1 in CSS21).  They do so by 
dividing up dependant boxes into what I call "painting layers".  The 
painting layers are, loosely speaking, the background of the painting 
context itself, followed by the backgrounds of in-flow non-positioned 
blocks, followed by the atomically-represented painting contexts formed 
by non-positioned floats, followed by the atomically-painted 
background+text of non-positioned inlines (the "content").  Boxes in the
same painting layer are painted in document tree order.

So I don't think you mean to say in your A3 above that inlines form
their own stacking contexts or, in your B1, that each child forms its
own stacking context.  I think you either mean to say "painting context"
or, more likely, simply "background+text atomic units".  It would be
helpful if you could clarify this.  The latter is equivalent to unifying
the painting layers for block backgrounds and inlines and following it
by the painting layer for floats.

[To put our earlier discussion into this context, I am opposed even to
children in B1 even forming background+text atomic units, let alone
painting contexts or stacking contexts.  (I'm pretty sure that you were
not really proposing either of the latter two.)]  The reason for my 
objection is also the answer to your question:

> Could you define conditions when these two schemas will produce
> different results? I cannot.

Yes.  As I explained in my earlier emails the issue here is overflow, 
caused for example by elements having fixed dimensions or 
max-dimensions.  (David Baron, in addition to affirming this, also 
mentioned small line-heights as causing overlap, but this is not 
relevant to the wider discussion because, overlapping or not, they are 
already rendered on the same painting layer.)

Let's use the simplified world-view you suggested, which happens to be 
that of CSS1.  The only painting contexts are the root element and 
floats, and the root element is the only true stacking contexts since 
there is no positioning.  Suppose the root element contains an in-flow 
child D1 with a fixed height which contains red-background text that 
overflows vertically -- perhaps because the user has increased the text 
size via their browser's UI -- and overlaps D1's subsequent sibling: an 
in-flow D2.  Retrospectively applying the current CSS21 stacking 
mechanism to CSS1 (which did not explicitly discuss stacking at all, 
AFAICT) we find (as a result of the painting layer order) that the 
overflowed text and its red background are rendered atomically above 
background of D2 but /underneath/ the text of D2, ensuring that all text 
is visible (albeit perhaps difficult to read).  In your schema B above, 
the red background of the the overflowed text renders on top of D2's 
text, resulting in D2's text being obscured.

If you now float D1 and give it a fixed width, and suppose that it 
contains a long unbreakable word that overflows horizontally, the word 
will also overlap D2's text (whose line boxes have been shortened to sit 
next to D1).  Again, under the current model we can still see all the 
text because the atomically-rendered float unit lies on a lower painting 
layer than D2's text, whereas under your schema B some of the text of D2 
is obscured by the red background of the overflowing text.

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Wednesday, 11 February 2009 12:39:05 UTC