Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[css-tables] How replaced elements are handled when receiving a table-* display type #508
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:
referenced this issue
Nov 11, 2016
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
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?)
You can repro (or try variants) using this gist:
Reporting back after having a look at the code. Our behavior was changed in Edge from returning
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
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
Face to face recommendation:
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.
The CSS Working Group just discussed
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
<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: 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