children of disclosure elements cannot inherit box-sizing: border-box from the parent disclosure
Categories
(Core :: Layout, defect)
Tracking
()
People
(Reporter: infinity0, Unassigned)
Details
Attachments
(1 file)
|
481 bytes,
text/html
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:106.0) Gecko/20100101 Firefox/106.0
Steps to reproduce:
html { box-sizing: border-box; }
*, *:before, *:after { box-sizing: inherit; }
This is the standard accepted way to make all elements on a page border-box by default, and it is considered superior to * { box-sizing: border-box } as it is easier to override subparts of the page back to content-box.
Actual results:
However it fails for a <details> disclosure box; its children somehow "inherit" content-box even though the parent element is in fact border-box; you can verify this easily in dev tools and the Computed Style.
One can work around this by setting the children explicitly back to border-box:
details > * { box-sizing: border-box; }
Expected results:
The same bug exists on Chrome/Chromium, which may suggest this is not a Firefox implementation problem. However, this is a very simple bug, yet I have been unable to find any resources explaining "oh actually this is the expected correct behaviour" and citing what part of the CSS standard that explains why <details> should be special in this way. (Nor a duplicate report in this tracker.) Furthermore multiple people have run into this issue online, not just me:
Therefore my current theory is it's a bug in both implementations. (Perhaps the same code got copied into both projects, I don't know.) If this is the case, I'd appreciate if you could file a bug to Chromium as well; I am unable to do so since I have lost access to my Google Account since 10 years ago for pseudo "security reasons" by using too many VPNs/Tor or something, and their support is terrible at resolving these issues.
|
||
Updated•2 years ago
|
|
||
Comment 2•2 years ago
|
||
The same bug exists on Chrome/Chromium, which may suggest this is not a Firefox implementation problem. However, this is a very simple bug, yet I have been unable to find any resources explaining "oh actually this is the expected correct behaviour" and citing what part of the CSS standard that explains why
<details>should be special in this way.
This is, in fact, the correct behavior. This is because <details> is implemented using Shadow DOM, and the <summary> inherits from the slot that's assigned to.
That is defined in https://html.spec.whatwg.org/#the-details-and-summary-elements, and here's an example that doesn't use anything fancy:
<!doctype html>
<style>
html { box-sizing: border-box; }
*, *:before, *:after { box-sizing: inherit; }
</style>
<div id="host">
<div id="slotted">This is content-box!</div>
</div>
<script>
document.getElementById("host").attachShadow({ mode: "open" }).innerHTML = `<slot></slot>`;
</script>
Hope that helps. Maybe worth filing an issue in whatwg/html? But this is one of the ways shadow dom is observable.
OK thanks for the explanation, upon a more detailed look it seems the issue is caused by * being defined in a precise way so as to exclude selecting the shadow root(s) generated by <details>. I have filed an issue to whatwg/html here: https://github.com/whatwg/html/issues/8583
Re-filed here as on second thought I figured it was more relevantly a CSS issue https://github.com/w3c/csswg-drafts/issues/8184
Thinking about it further, I am not sure if it is a bug in the spec, either HTML or CSS. If we say
details > summary { }
Any definitions in here get applied correctly, as the implementation thinks <summary> is a direct child of <details> i.e. <details> is the parent.
The problem comes when we use summary { box-sizing: inherit; } in this case the inherited value comes from the <slot> parent in the shadow DOM. This is inconsistent with the previous behaviour. The absurdity becomes apparently when we say:
details > summary { box-sizing: inherit; }
yet the summary does not inherit from details!
In fact, css-scoping-1 [1] even explicitly says:
"The top-level elements of a shadow tree inherit from their host element."
which is ironically exactly what I suggested as an option in my bug report.
So do you agree that this is in fact an implementation issue, that the behaviour is not correct?
[1] https://www.w3.org/TR/css-scoping-1/#inheritance
[2] https://github.com/w3c/csswg-drafts/issues/8184#issuecomment-1336579859
In fact, css-scoping-1 [1] even explicitly says:
"The top-level elements of a shadow tree inherit from their host element."
which is ironically exactly what I suggested as an option in my bug report.
Sorry, I misread this; this is consistent with the current behaviour. What I suggested instead would be that for the elements of a shadow tree, that were taken from the host element's real tree (which are not necessarily top-level elements of the shadow tree), these elements should inherit from their parent in the original host tree rather than their new parent in the shadow tree. So the spec could still be fixed in this way.
The justification would be that the current behaviour of
details > summary { box-sizing: inherit; }
is absurd.
I guess in implementations, the <details> node still keeps child-links to the <summary> node, and that is how it gets selected by ">", but when walking back up the tree for "inherit" the <summary> node's parent now points to the <slot> in the shadow tree.
|
|
||
Comment 7•2 years ago
|
||
This is all working as expected. CSS inheritance and selector matching work on different trees, see https://drafts.csswg.org/css-scoping-1/#flattening
Description
•