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

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

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

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

~Daniel

Received on Monday, 3 August 2015 19:58:24 UTC