Reputation: 2131
I discovered that <details>
is rendered differently between Chrome and Firefox. See the code example below.
According to HTML Standard:
The first summary element child of the element, if any, represents the summary or legend of the details. If there is no child summary element, the user agent should provide its own legend (e.g. "Details").
The rest of the element's contents represents the additional information or controls.
The open content attribute is a boolean attribute. If present, it indicates that both the summary and the additional information is to be shown to the user. If the attribute is absent, only the summary is to be shown.
And according to CSS Standard:
When their computed content value is not none, these pseudo-elements generate boxes as if they were immediate children of their originating element, with content as specified by content.
::before represents a styleable child pseudo-element immediately before the originating element’s actual content. ::after represents a styleable child pseudo-element immediately after the originating element’s actual content.
On Chrome and Chromium based browsers, ::before
and ::after
are displayed respectively before <summary>
and after the additional information, whatever the open
attribute is present or not. As I understand, <summary>
is part of the details actual content, even if the tag is not defined but generated by the browser???
On Firefox, ::before
and ::after
are displayed after <summary>
and around the additional information if the open
attribute is present, else only the summary is shown. Based on the CSS definition, this suggests that <summary>
is not part of details actual content. This behavior is consistent with <fieldset>
where ::before
is also displayed after <legend>
. However, I would expect that the two pseudo-elements remain always visible because <details>
is still visible when closed.
So what should be the correct behavior?
details::before {
content: "before";
color: red;
}
details::after {
content: "after";
color: green;
}
<details>
<summary>Closed details</summary>
<p>
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
</p>
</details>
<details open>
<summary>Open details</summary>
<p>
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
</p>
</details>
Upvotes: 3
Views: 538
Reputation: 83125
From the quotes you give, it seems that Chromium is in violation of the HTML requirements (should not be shown when details is closed) and Firefox is in violation of the CSS requirements (::before should precede the summary).
However, we also have the rendering requirements from the HTML specification, which for details/summary says:
The details element is expected to render as a block box. The element is also expected to have an internal shadow tree with two slots. The first slot is expected to take the details element's first summary element child, if any. The second slot is expected to take the details element's remaining descendants, if any.
So we only have two slots, and one slot is dedicated to the summary element. The other slot takes the remaining content, including that of the ::before and ::after pseudo elements. Such an arrangement can only be consistent with Firefox's behaviour.
Update: It turns out that the conclusion of the above answer is incorrect, at least according to Chrome's dev's - See the bug report.
Apparently, pseudo-elements do not ever participate in the slotting process, possibly because the process of slotting is a DOM - specifically a shadow DOM - operation. As such, at the time of slotting, pseudo elements - which are generated by the application of styling - don't exist, and therefore cannot participate in the slotting process. So they end up getting added at a later time in the rendering process around the entire already slotted arrangement, making Chromium's behaviour correct.
Upvotes: 4