[Inactive CSS] Display a warning when table-layout is used incorrectly
Categories
(DevTools :: Inspector: Rules, enhancement, P3)
Tracking
(firefox87 fixed)
Tracking | Status | |
---|---|---|
firefox87 | --- | fixed |
People
(Reporter: miker, Assigned: sebo)
References
(Blocks 1 open bug)
Details
(Keywords: dev-doc-complete, Whiteboard: [Importance: 38.8%])
Attachments
(1 file)
Valid for table and inline-table elements:
[
"border-collapse",
"border-spacing",
"table-layout",
]
Comment 1•5 years ago
|
||
Hi, I'd like to try my hand at completing this as a first-time contributor.
Reporter | ||
Comment 2•5 years ago
|
||
(In reply to James Ah Yong from comment #1)
Hi, I'd like to try my hand at completing this as a first-time contributor.
We have assigned you to the bug... if you have any questions then please don't hesitate to ask.
Reporter | ||
Updated•5 years ago
|
Comment 3•5 years ago
|
||
(In reply to Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe] from comment #2)
(In reply to James Ah Yong from comment #1)
Hi, I'd like to try my hand at completing this as a first-time contributor.
We have assigned you to the bug... if you have any questions then please don't hesitate to ask.
I've been fiddling around with border-spacing
and realized that the property currently applies to all non-root table elements whether or not they are properly inside of a root table element. For example, the following code has a div
without display:table
which still functionally acts like a table.
<div style="display:block; border-spacing:1rem">
<div style="display:table-row">
<div style="display:table-cell">1</div>
<div style="display:table-cell">2</div>
</div>
</div>
I tried to make sense of the standard's language governing border-spacing
(applies to "a table or inline-table box") and it seems to me like that it should not apply in that scenario. Is this intended behaviour and if so, should the invalid CSS rule follow?
Updated•5 years ago
|
Comment 4•5 years ago
|
||
Hey James. I was wondering if you were still intending on working on this bug?
I noticed you were asking Mike a question in comment 3, but the needinfo
flag was not set, so I'll set it for you so Mike can see the request.
Please let me know if you'd still be interested in this bug or not.
Reporter | ||
Comment 5•5 years ago
|
||
(In reply to James Ah Yong from comment #3)
(In reply to Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe] from comment #2)
(In reply to James Ah Yong from comment #1)
Hi, I'd like to try my hand at completing this as a first-time contributor.
We have assigned you to the bug... if you have any questions then please don't hesitate to ask.
I've been fiddling around with
border-spacing
and realized that the property currently applies to all non-root table elements whether or not they are properly inside of a root table element. For example, the following code has adiv
withoutdisplay:table
which still functionally acts like a table.<div style="display:block; border-spacing:1rem"> <div style="display:table-row"> <div style="display:table-cell">1</div> <div style="display:table-cell">2</div> </div> </div>
I tried to make sense of the standard's language governing
border-spacing
(applies to "a table or inline-table box") and it seems to me like that it should not apply in that scenario. Is this intended behaviour and if so, should the invalid CSS rule follow?
From:
https://www.w3.org/TR/CSS2/tables.html - 17.2.1 Anonymous table objects
Document languages other than HTML may not contain all the elements in the CSS 2.1 table model. In these cases, the "missing" elements must be assumed in order for the table model to work. Any table element will automatically generate necessary anonymous table objects around itself, consisting of at least three nested objects corresponding to a 'table'/'inline-table' element, a 'table-row' element, and a 'table-cell' element. Missing elements generate anonymous objects (e.g., anonymous boxes in visual table layout) according to the following rules:
For the purposes of these rules, the following terms are defined:
row group box
A 'table-row-group', 'table-header-group', or 'table-footer-group'
proper table child
A 'table-row' box, row group box, 'table-column' box, 'table-column-group' box, or 'table-caption' box.
proper table row parent
A 'table' or 'inline-table' box or row group box
internal table box
A 'table-cell' box, 'table-row' box, row group box, 'table-column' box, or 'table-column-group' box.
tabular container
A 'table-row' box or proper table row parent
consecutive
Two sibling boxes are consecutive if they have no intervening siblings other than, optionally, an anonymous inline containing only white spaces. A sequence of sibling boxes is consecutive if each box in the sequence is consecutive to the one before it in the sequence.
So an anonymous internal table box is created when you add a table-row
box so the border spacing should be applied in your scenario.
Reporter | ||
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 6•4 years ago
|
||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 7•4 years ago
|
||
(In reply to Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe] from comment #0)
[
"border-collapse",
"border-spacing",
Per my notes in bug 1583901 comment 9 onwards, and the code-comment added in bug 1688538, I think we shouldn't actually add a warning about these two properties, because they are inherited-by-default, which makes it hard to reason about whether they're truly inactive (in the element's whole subtree) or not.
"table-layout",
This one, however, does not inherit by default (per https://developer.mozilla.org/en-US/docs/Web/CSS/table-layout and https://www.w3.org/TR/CSS2/tables.html#width-layout ) which means it probably would still make sense to warn about this one.
Updated•4 years ago
|
Assignee | ||
Comment 8•4 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #7)
"table-layout",
This one, however, does not inherit by default (per https://developer.mozilla.org/en-US/docs/Web/CSS/table-layout and https://www.w3.org/TR/CSS2/tables.html#width-layout ) which means it probably would still make sense to warn about this one.
I've changed the summary to reflect that.
Sebastian
Comment 10•4 years ago
|
||
bugherder |
Assignee | ||
Comment 11•4 years ago
•
|
||
This might be worth mentioning in the release notes for 87 together with the change in bug 1671457.
Sebastian
Comment 12•4 years ago
|
||
Documentation done; see https://github.com/mdn/content/issues/2505
Description
•