Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
gregwhitworth opened this issue Sep 21, 2016 · 11 comments

Comments

6 participants
@gregwhitworth
Copy link
Contributor

commented Sep 21, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Oct 29, 2016

Supersedes #398

@gregwhitworth

This comment has been minimized.

Copy link
Contributor Author

commented Nov 11, 2016

@dbaron

This comment has been minimized.

Copy link
Member

commented Nov 11, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Nov 14, 2016

Here is an excel spreadsheet I made:
image

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

@FremyCompany

This comment has been minimized.

Copy link
Contributor

commented Nov 14, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Nov 15, 2016

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

This comment has been minimized.

Copy link
Contributor Author

commented Nov 16, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Nov 25, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Jul 24, 2017

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

This comment has been minimized.

Copy link
Member

commented Jul 24, 2017

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.

@astearns astearns removed the Agenda+ F2F label Aug 1, 2017

@css-meeting-bot

This comment has been minimized.

Copy link
Member

commented Aug 3, 2017

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.