W3C home > Mailing lists > Public > www-style@w3.org > August 2015

Re: [css-containment] What does "contain:layout" do on table parts?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 3 Aug 2015 11:22:56 -0700
Message-ID: <CAAWBYDCxm8F+rQaUzQa47F-H=6W_peyTsZctOYV9a4ZHRUj4hA@mail.gmail.com>
To: Daniel Holbert <dholbert@mozilla.com>
Cc: "L. David Baron" <dbaron@dbaron.org>, www-style list <www-style@w3.org>
On Fri, Jul 31, 2015 at 10:50 AM, Daniel Holbert <dholbert@mozilla.com> wrote:
> On 07/31/2015 08:52 AM, L. David Baron wrote:
>> I think the "must be a formatting context" bit of
>> https://drafts.csswg.org/css-containment/#containment-layout ought
>> to mean that it's not possible for internal table parts to have
>> contain:layout, since they get changed into something else.  (The
>> spec doesn't define what, though.)
> I don't think Tab's envisioned "FCifying" process actually changes the
> display values of table-parts. [though maybe it should?]
> Tab clarified his thoughts on what FCifying means for various display
> types here:
>  https://bugzilla.mozilla.org/show_bug.cgi?id=1179349#c2
> ..and in particular, he said this about FCifying for various display
> values:
>> table-* types will do nothing.
> So according to that, it *would* be possible to have a
> table-row/row-group/cell/etc. with "contain:layout".

On the other hand, I might be wrong. ^_^

I am, personally, okay with the table-row collapsing to nothing, table
layout taking place as if the row was empty, and then the cells (a)
taking their widths from the table columns, which were calculated
without them, possibly causing inline overflow in each cell, and (b)
overflowing the row, overlapping the next visibly.

But I completely understand if that's not really possible (or at
least, not without a lot of trouble) for our actual codebases, which
might make some assumptions about tables that are difficult/dangerous
to violate.  Is that the case?  If so, let's discuss what we *can* do
with this case.  I'm biased toward doing something simple and
predictable, because this is an edge case that I don't actually care
about or think people should do.  For example, having FCification
force it to "display:flow-root" (or display:block + BFC) is a fine
answer; it won't do what the author wanted, but it's simple and easily
extends to other display models that might not allow their internal
display types to be FCs, like ruby.

Received on Monday, 3 August 2015 18:23:44 UTC

This archive was generated by hypermail 2.3.1 : Monday, 3 August 2015 18:23:45 UTC