-
Notifications
You must be signed in to change notification settings - Fork 658
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
Flattened element tree and pseudo-elements #3126
Comments
I personally don't see a logical need for slotting However, I'm sure there are cases where it could be useful to reposition CSS generated content. For example, if you have a If they were to be slottable in the template, how would that work? A More comments on the specifics of details/summary vs fieldset/legend on the other issue: whatwg/html#3805 (comment) |
I think I wouldn't like to implement this in Gecko. This means layout needs to shuffle pseudo-elements around and figure out the right insertion point when slots gets changed and moved around, feels a bit of a layering violation that DOM needs to care about pseudo-elements for slotting. Also this would have implications... An element with a pseudo-element would no longer display the slot's fallback, right? Which means that there's no way to have both fallback and pseudo-elements at the same time. So from an author's perspective doesn't sound as great either. There'd also be no way to assign a pseudo-element to a non-default slot (or keeping the usual behavior) without even more special-casing... |
That makes sense, the motivation was making |
I would prefer we not define That's why we defined 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 That way, |
Rather than using This would solve a number of problems all at once:
If this sounds like something worthwhile, I'm happy to help write up spec text. I expect it would be defined in HTML. |
In whatwg/html#3805 a concern was raised by @bzbarsky (perhaps on behalf of @MatsPalmgren) that expressing
details
through shadow trees results in a placement of::before
and::after
that's not desirable.So the question is whether
::before
and::after
on a host element should perhaps be shadow tree aware and end up "assigned" to a slot. This would perhaps be somewhat more natural given that element children end up being assigned.cc @zcorpan @emilio @hayatoito @rniwa
The text was updated successfully, but these errors were encountered: