- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Fri, 21 Sep 2018 21:36:38 +0000
- To: public-css-archive@w3.org
I would prefer we *not* define `details` the same way as `fieldset`; magical rendering that can't be reproduced by users of the platform is something to be avoided whenever possible. That's why we defined `details` in terms of shadow DOM - it was the only way to explain the rendering using the platform. And thus the behavior of ::before/::after falls out of that, matching how it works with every other shadow-dom–using component in the world — ::before/::after get jammed into the flat tree as the first/last child of the originating element. So yeah, they show up whether the `details` is open or closed, and ::before will precede the `summary` in either case. I'm potentially open to the idea of letting a host element describe where it would like its ::before/::after to go. I think I'd prefer, tho, just continuing to develop and support `::part()`, which allows ::before/::after on it, and then defining the name of the built-in `details` part so authors can target it. That way, `details::before` would work as today, with the ::before showing up all the time, and before all other content including `summary`; `details::part(content)::before` would only show up when the `details` was open, and would just go at the start of the content, *after* the `summary`. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3126#issuecomment-423677427 using your GitHub account
Received on Friday, 21 September 2018 21:36:39 UTC