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