W3C home > Mailing lists > Public > www-style@w3.org > May 2013

Re: [CSS21] table cells establishing pseudo-stacking contexts (was Re: [CSSWG] Minutes Telecon 2013-04-05)

From: L. David Baron <dbaron@dbaron.org>
Date: Mon, 27 May 2013 18:40:54 +0800
To: fantasai <fantasai.lists@inkedblade.net>
Cc: www-style@w3.org
Message-ID: <20130527104054.GB12096@crum.dbaron.org>
On Wednesday 2013-05-01 17:52 -0700, fantasai wrote:
> On 05/01/2013 04:28 PM, L. David Baron wrote:
> >On Wednesday 2013-05-01 15:32 -0700, fantasai wrote:
> >>
> >>So I think from an authoring perspective, it makes the most sense to
> >>do model A for separate-border tables, and model B for collapsed-border
> >>tables.
> >
> >I think it's way too complex to have two models here.  We should
> >pick one.  What's wrong with using (b) for both?
> 
> Mainly that table cells can't be transformed together with their
> backgrounds. I'm not sure how much of a problem that is for people,
> but it's a capability we'd lose that sort-of works right now.

Transforming makes a real stacking context, though it's really not
at all clear in any spec what that means inside of tables.  There's
certainly precedent in Gecko [1] and in your tests [2] for honoring
the formation of real stacking contexts during table background
painting, and separating the various layers between the relevant
stacking contexts.  But CSS 2.1 makes no attempt to specify what
happens when the root of a stacking context is a table cell, row,
column, row-group, or column-group.  (In CSS 2.1 there's technically
no such case defined since position:relative's behavior on table
parts is explicitly undefined [3], but later modules introduce
'opacity', 'transform', and other properties.)

It also seems like the behavior of transforms on table cells is not
interoperable, though, based on the behavior of your testcase in IE.
(Though IE is going towards model (A), whereas I'd like to stick
with (B).)

http://www.w3.org/TR/CSS21/zindex.html pretty clearly specifies
model (B), now that I look at it (in items (2), (4), and
(7.2.1.4.b.1)).  In other words, most of the message I sent that
started this thread,
http://lists.w3.org/Archives/Public/www-style/2013Apr/0145.html ,
was based on incorrect premises about what was in which layer.


I think this is a mess, partly as a result of things being too
complicated.  I don't think the answer is making them more
complicated, especially given how little authors actually seem to
care about these issues.

I'd sort of like to revert the change we agreed a few months ago to
make table cells pseudo-stacking contexts... except that I don't
know if it actually solves anything, since we do already have a spec
that says we take option (b), and we still have a lot of undefined
behavior either way.

(The presence of lots of undefined behavior makes me inclined not to
invest in fixing the relevant Gecko bugs such as [4], since when
that undefined behavior gets defined the code written to fix those
bugs will have to be rewritten yet again.)

-David

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=4510
[2] http://fantasai.tripod.com/www-style/2002/table-backgrounds/tests/layers-opacity.html
[3] http://www.w3.org/TR/CSS21/visuren.html#propdef-position
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=858333

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂
Received on Monday, 27 May 2013 10:41:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 27 May 2013 10:41:28 UTC