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.

Supersedes #398

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

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

Here is an excel spreadsheet I made:

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

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.

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?

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?

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

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)

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.