-
Notifications
You must be signed in to change notification settings - Fork 705
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] Display: sub-row #5316
Comments
I think inserting extra rows in some cases but not in others may break |
I understand the use case. But this doesn't seem reasonable to me, implementation wise. The only way to know is to fully layout the whole table once, then throw everything out and restart if something happened to the notes. Tables having already two layout passes, that sounds extra bad. |
I understand. Would it make a significant difference if the default was not the cell-like behavior but the row-like behavior.? |
PS: This would, in some way, be similar to |
I realize that this would probably need to apply to all cells within a column collectively, so maybe this should work (only) with elements that otherwise have col.note {display: table-column-runin;} Dunno. In #11499 I suggested that it might be necessary to represent HTML attributes td, th {
display: table-cell;
table-span: attr(rowspan type(<integer>), 1) attr(colspan type(<integer>), 1);
} Then it could be possible to solve this use case by other means: td.note, th.note,
col.note || :is(th, td) {
table-slot: 1 new-row-after;
table-span: all-remaining-cols 1;
} |
Table cells that wrap inside because they can have a lot of textual content, e. g. in columns labeled Notes or Comment, are a common problem in data tables which otherwise tend to have narrow columns. To deal with this in responsive layouts that must work on narrow screens without horizontal scrolling or in printouts, some designers do not use HTML tables and the CSS layout model informed by them, but fake it with different elements and
display
values.I think a new value
table-sub-row
could deal with a lot of use cases: it would default to the same behavior astable-cell
, but if its content needed to wrap and its height would therefore become greater than its parenttable-row
, it would instead display like a single cell spanning all columns in a new display row after the current one.It becomes more complicated to specify, of course, if multiple cells in a row have this display value and if they should be able to share horizontal space by automatically distributing the available width. I think, though, that it is quite doable if every sub-row just spans the complete width.
The text was updated successfully, but these errors were encountered: