[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 <input style="table-cell"> 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 <input type="button"> as a bug for Edge and <input type=file> 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

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