- From: L. David Baron <dbaron@dbaron.org>
- Date: Sat, 6 Apr 2013 14:16:02 -0400
- To: www-style@w3.org
On Friday 2013-04-05 15:19 -0700, fantasai wrote:
> Flexbox
> -------
>
> <SimonSapin> http://lists.w3.org/Archives/Public/www-style/2013Mar/0707.html
> Tab: Issue on flex items painting atomically was decided in July;
> decided not to make them pseudo-stacking contexts, for consistency
> with table cells.
> Tab: But thinking about it more. we should make flex items, grid items,
> and table cells all paint atomically.
> <SimonSapin> Do we have a level 3 module that defines stacking contexts?
> <fantasai> css-position-3, I think
>
> Tab: The only way to tell whether they paint like table-cells or atomically
> is to move a float outside the box and then back in via negative
> margins.
> Tab: In this case the float is between the content and the background in
> a table-cell and over or under both in the atomic version
> Tab: Table-cells become a pseudo-stacking context, not a full stacking
> context.
> Tab: Desire is to make this change, retroactively, in CSS2.1
> Note CSS2.1 already has changes that require a PER to update the spec
> <tantek> I agree with making this an errata to 2.1
>
> Tab: It might be OK to say that, even if table-cells do not change, all
> future layout models will use pseudo-stacking contexts
> Anton: We can do this for flexbox and grid, even without making the
> change to table-cells
> Fantasai: the main reason for copying table-cells in July was "consistency"
> and no one had a reason for breaking that. We now have such
> an argument.
> Tab: Grid really wants to be atomic because Grid does a lot of overlapping
> Tab: any objection to making Flexbox pseudo-staking contexts?
> plinss, Anton: not sure
>
> <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Jul/0265.html
> fantasai: minutes ^
> Fantasai: noted that Anton argued for pseudo-stacking context in July
> plinss: how about separating the foregrounds and backgrounds and paint
> each separately
> Tab: no, for grid items if you put an item on top of another you want
> the background of the top item to obscure the lower one.
> plinss: might want to add a switch to interleave the backgrounds
> plinss: whether this change affects tables is up to the vendors and the
> degree of compatibility impact
> Tab: Google thinks this is probably OK to change and dbaron seems to
> believe so also
> RESOLVED: make table-cell, flex item and grid item form pseudo-stacking
> contexts
It occurs to me that it's actually not entirely clear what it means
to change table cells to be pseudo stacking-contexts. In
particular,
http://www.w3.org/TR/2011/REC-CSS2-20110607/tables.html#table-layers
describes the model through which cell, row, row group, column,
column-group, and table backgrounds operate.
My interpretation of this model is that, effectively, backgrounds on
all of these table parts *except for the table itself* are drawn by
the cells, since they are both (a) clipped to cell boundaries and
(b) extended by column-spans and row-spans.
When cells are not pseudo-stacking contexts, there's no issue here,
because all of the backgrounds are drawn in the background layer,
and there's no possibility for backgrounds to overlap with anything
else.
However, if cells are pseudo-stacking contexts, then the background
of a later cell can draw on top of the content of an earlier cell.
This requires, in turn, defining exactly *which* of these table part
backgrounds are part of the pseudo-stacking context established by
the table cell.
Combining these two makes me think that, in turn, if cells are to be
pseudo-stacking contexts, then either:
(a) the backgrounds of all of the table parts except for the table
(i.e., column groups, columns, row groups, rows, and cells)
should be part of background layer in the pseudo-stacking
context established by the cell, or
(b) none of the backgrounds (not even the cell's) should be part of
the pseudo-stacking context established by the cell.
I don't have a strong preference between these options. However, I
would be opposed to other options, such as including the table's
background in the cell's pseudo-stacking context, or including the
cell background but none of the other table part backgrounds,
because I don't think these options fit with the existing model, and
thus I think they would lead to extra implementation complexity and
extra difficulty for authors who want to understand what's
happening.
-David
--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla http://www.mozilla.org/ 𝄂
Received on Saturday, 6 April 2013 20:52:22 UTC