[css-tables] How replaced elements are handled when receiving a table-* display type

[gregwhitworth]

We have changed the spec from 2.1 regarding replaced elements as no browser currently allows this. Here is the spec text regarding this change:

Authors must not assign a display type from the previous list to replaced elements (like input fields or images).

When the 'display' property of a replaced element computes to one of these values, it is handled instead as would inline (for inline-table, table-cell, table-column) or block (for all other values).

Whitespace collapsing and box generation must happen around those replaced elements like if they never had any other display type.

[FremyCompany]

Supersedes #398

[gregwhitworth]

Here is the testcase linked in 470: https://rawgit.com/w3c/csswg-test/css-tables/work-in-progress/microsoft/css-tables/table-model-fixup-2.html

[dbaron]

It might be preferable to use a should not rather than a must not for the author requirement; I think we've shied away from using must-level requirements on authors, since we know they're not actually going to be honored.

I think the "like if they never had any other display type" is ambiguous as to which "other" it's referring to: does it mean the table-* type or its inline or block replacement.

I'm curious if you have data on how well this matches existing implementations. (E.g., do they follow this block/inline distinction, and do they follow these rules for anonymous box generation and whitespace collapsing?)

[FremyCompany]

Here is an excel spreadsheet I made:

You can repro (or try variants) using this gist:
https://gist.github.com/FremyCompany/aada819289924585d63737a7622d4c44

[FremyCompany]

As far as I can remember, I found out that in all browsers, consecutive did form a single cell as if table-cell never had been set on them. I didn't check whitespace collapsing but I assume the same applies there.

[FremyCompany]

Reporting back after having a look at the code. Our behavior was changed in Edge from returning block for every element to return something similar to Chrome and Safari. 

The spirit was that replaced elements except form fields should behave as block, and form fields elements as inline. It doesn't make much sense to me that table-row wouldn't be a block on an input or that table-cell might be a block on some other elements, but I would be fine to change the spec to match it if this is what people believe is best. 

That would still leave as a bug for Edge and as a bug for Chrome. 

What do you think?

[gregwhitworth]

Ok, so I've made the small editorial change for the author advisement. That last line is quite confusing since we're saying, actually we're just going to set them to an inline or block, but then never get around to describing those implications. My assumption is that fixup and whitespace collapsing will work as normal following what is specified, but the the layout of the box itself will be that of inline or block; is this correct?

[FremyCompany]

The proposal would be to work as if the box had display:block instead of display:table-xyz; there would be no visible effect that display was specified to table-xyz (the computed value of the property should be block, I guess, or at least the used value).

[FremyCompany]

Summary of the discussion

CSS 2.1 advised browsers to support setting table-related displays on replaced elements. For instance, setting display:table-row on a replaced element would be a way to make it create its own row and span all columns of the table it is in. There was however no attempt made to describe how that would even work.

All browsers agree that replaced elements should never become table-internal elements but there are differences in how they fallback to either block or inline display.

The new spec defines the implemented behavior and clarifies how fallback works in those cases.

Face to face recommendation:

We want this breaking change to be resolved on. We propose to vote between

1. spec (row->block + column->inline) or
2. firefox (all->inline) behavior.

Examples:

#508 (comment)

[tabatkins]

I think we've shied away from using must-level requirements on authors, since we know they're not actually going to be honored.

Some people dislike them, but I still use them; the intent of must vs should is still clear, even if we know many authors will do it anyway.

[css-meeting-bot]

The CSS Working Group just discussed replaced elements as table cells, and agreed to the following resolutions:

• RESOLVED: All internal table displays on replaced elements to behave as 'inline'.
• RESOLVED: table falls back to block, inline-table falls back to inline

The full IRC log of that discussion

Topic: replaced elements as table cells
gregwhitworth: We added a diagram of what the spec says to do
github: https://github.com//issues/508
https://github.com//issues/508#issuecomment-260486721
gregwhitworth: Made a table of results
gregwhitworth: what we tried to do, where it behaved more like block, specified to be as block
gregwhitworth: if behaved more like inline, specified as inline
gregwhitworth: we dont' have a strong pref
gregwhitworth: This is 1st to discuss
dgrogan: WE talked about this in Chrome, don't want to defend our behavior. I todesn't make much sense
gregwhitworth: For firefox, we prefer firefox behavior
gregwhitworth: It seems like author did something wrong, so make it more obvious it's wrong
dbaron: One question here is do you do anonymous box construction around these things
gregwhitworth:
gregwhitworth: no
dbaron: Do you think some of these results are because of anonymous box construction?
gregwhitworth: they don't create separate cells
fantasai: They wouldn't, if they did anonymous box construction ...?
gregwhitworth: ...
gregwhitworth: So besides Chrome having pref, anyone else?
Rossen: So path forward is to fall back to Firefox's behavior?
fantasai: Seems to me that making it block would make more sense
fremy: Wouldn't be Web-compatible
gregwhitworth: Any objection to resolve on Firefox's behvaior?
RESOLVED: All internal table displays on replaced elements to behave as 'inline'.
RESOLVED: table falls back to block, inline-table falls back to inline
tantek: Point about anonymous box construction, are there tests ?
gregwhitworth: I'm sure we have tests for it somewhere
tantek: ...
fantasai: What do you mean anonymous boxes don't get constructed?
dbaron: Do individual things create individual table cells, or group together into one cell
dbaron: Do different things depending on row-group vs table-cel etc
tantek: Based on what dbaron said, maybe just copy what Firefox does
The resolution is specific about what the behavior is
fantasai: If it's defined as "behave as inline", then anonymous box construction is defined
dbaron: Could do anonymous box before, rather than after treating as inline
... and it is not "just repeat what Firefox does"
fantasai: That would end up with improper table structures, which the spec does not allow

[frivoal]

FWIW, http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=9229 tests this for table-caption