Re: [css3-flexbox] Paint flex items atomically?

On Monday 2012-07-09 18:12 -0700, fantasai wrote:
> On 07/02/2012 12:15 PM, Anton Prowse wrote:
> >On 28/06/2012 11:00, Morten Stenshorne wrote:
> >>Should flex items be treated as if they sort of establish a new stacking
> >>context (except for descendants that are positioned or create true
> >>stacking contexts on their own)? I'm talking about what
> >>http://www.w3.org/TR/CSS2/zindex.html has to say about inline-block,
> >>inline-table and floats.
> >
> >It's certainly a reasonable question to think about. I think I probably prefer them not to, in order to make overflow more
> >accessible; but I could easily live with them doing so, too. My guess is that implementers will prefer them to do so, since in
> >a multiline flexbox perhaps you wouldn't be able to paint the inline content inside each item (which might overflow
> >vertically) in the first line until you'd already figured out and painted the backgrounds of the items in the second line,
> >etc. This situation already occurs in normal block/inline layout, of course, but I sense that that flex items will be given
> >fixed heights more often than normal blocks.
> >
> >(Don't forget that any element can be turned into one which creates a pseudo-stacking context by giving it
> >position:relative;z-index:auto.)
> 
> I've written up this issue here:
>   http://wiki.csswg.org/topics/flex-item-painting

I have a few (inconclusive, unfortunately) comments on this.

What the diagram there refers to as a "stacking container" has
previously been referred to most often as a "pseudo stacking
context" and also as a "painting context". [1]  This concept exists
to support the statement in CSS 2.0 that inlines should paint on top
of floats that they overlap, but floats should paint on top of block
backgrounds.

First, I think this entire concept was probably a mistake, and
floats should have just painted on top of inlines that were forced
into overlapping them (which is very rare).  This was a case of
inferring a substantial amount of meaning (as I did in [4]) out of a
very small piece of spec text, which I think is one of the worst
mistakes spec writers and interpreters can make [5].  That mistake
is not correctable, however, because the behavior of painting all
inlines on top of all blocks is, I believe, pretty important for
displaying Web content properly (though I think it may not have been
at the time of [4]), particularly for the case of negative vertical
margins on blocks.

Second, I think it was a smaller mistake, and possibly still
correctable, that we didn't make everything that establishes a new
block formatting context also establish a new pseudo stacking
context.  Both concepts exist because of the need to contain floats
and the inlines that wrap around them.  I think [1] tends towards
this position by requesting that we change one of the two exceptions
(overflow!=visible; the other exception is table cells and captions).
However, given the interoperability on [2] I suspect we may not be
able to, though I've only tested Firefox and Chrome so far.

This I see the following weak arguments for proposal B, that flex
items should establish new pseudo stacking contexts:

a. Having more things create pseudo stacking contexts is likely to
   reduce author confusion since they inhibit a behavior that
   authors may find confusing.

b. Aligning the concepts of block formatting contexts and pseudo
   stacking contexts as much as possible (particularly if we can do
   so completely) has the advantage of reducing the number of
   concepts in CSS.

And I see the following weak arguments for proposal A, that they
should not:

c. It would be more consistent, given that table cells and captions
   and overflow!=visible don't follow the rule I suggested in the
   paragraph above beginning with "Second", that the consistent
   behavior to follow is that display:inline-* establishes a new
   pseudo stacking context, but other things that establish new
   block formatting contexts do not.

d. The argument (b) above for aligning is not relevant given that
   we probably can't do so for compatibility.

(That said, I think proposal A must implicitly include the proposal
that display:inline-flex create a new pseudo stacking context, just
as inline-block and inline-table do.  In other words, something in
the spec should say that inline-flex is inserted into the "For
inline-block and inline-table elements" clause in bullet 7.2.1.4 of
[3].  In fact, I think that change should probably be made with
either proposal.)

I actually can't decide which I prefer.

-David

[1] http://lists.w3.org/Archives/Public/www-style/2009Feb/0340.html
[2] http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Ctable%3E%0A%3Ctr%3E%3Ctd%3E%3Cdiv%20style%3D%22margin-top%3A%202em%3B%20margin-bottom%3A-2em%3B%22%3EIf%20this%20text%20shows%20up%20the%20table%20cell%20exception%20is%20implemented.%3C%2Fdiv%3E%3C%2Ftd%3E%3C%2Ftr%3E%0A%3Ctr%3E%3Ctd%3E%3Cdiv%20style%3D%22background%3Ayellow%3B%20height%3A%202em%22%3E%3C%2Fdiv%3E%3C%2Ftd%3E%3C%2Ftr%3E%0A%3C%2Ftable%3E%0A%0A%3Cdiv%20style%3D%22overflow%3Ahidden%3Bmargin-top%3A%202em%3B%20margin-bottom%3A-2em%3B%22%3EIf%20this%20text%20shows%20up%20the%20overflow%20exception%20is%20implemented.%3C%2Fdiv%3E%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22overflow%3Ahidden%22%3E%3Cdiv%20style%3D%22background%3Ayellow%3B%20height%3A%202em%22%3E%3C%2Fdiv%3E%3C%2Fdiv%3E%0A
[3] http://www.w3.org/TR/CSS2/zindex.html#painting-order
[4] http://lists.w3.org/Archives/Public/www-style/1999Sep/0064.html
[5] http://dbaron.org/log/20100531-specs

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂

Received on Wednesday, 11 July 2012 05:03:05 UTC