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 14:47:48 -0700
Message-ID: <CAAWBYDBQ7XCcO69pMn7V6F8DasjMfMWEuof2UTTXOJo9Uf0aZA@mail.gmail.com>
To: Daniel Holbert <dholbert@mozilla.com>
Cc: "L. David Baron" <dbaron@dbaron.org>, www-style list <www-style@w3.org>
On Mon, Aug 3, 2015 at 12:57 PM, Daniel Holbert <dholbert@mozilla.com> wrote:
> On 08/03/2015 11:22 AM, Tab Atkins Jr. wrote:
>> 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.
> This could be reasonable behavior, yeah.
> (border-collapsing around a "contain:layout" row would probably require
> some special-case coding & and perhaps speccing, too. I think the rows
> on either side of a 'contain:layout' row would need to have their cells'
> borders collapse together, as if the row in between them were really empty.)

Never mind, too much special-casing, abort abort abort.

>> 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?
> For Gecko at least, I think it's possible. Not sure how much trouble
> it'd be; I think it'd mostly just require a bunch of special cases, and
> probably some refactoring to support those special cases.

Not worth adding a bunch of special-casing for a case that nobody
cares about in the first place.

>> 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;
> I like the simplicity of having "contain:paint/layout" (i.e.
> FCification) promote most display types to "display:block" or
> "inline-block", personally -- with flex/inline-flex & grid/inline-grid
> display values being the exception.  (I think dbaron is in favor of
> something along those lines, too.)

I think of it the other way - most layout types FCify in a normal
fashion, but a few special-case internal ones give up and become block
BFCs.  But sure. ^_^

Received on Monday, 3 August 2015 21:48:34 UTC

This archive was generated by hypermail 2.3.1 : Monday, 3 August 2015 21:48:35 UTC