- From: Noam Rosenthal via GitHub <noreply@w3.org>
- Date: Wed, 06 Aug 2025 11:14:20 +0000
- To: public-css-archive@w3.org
> It's definitely an interesting proposal. It's not _quite_ a slot tho, since a slot contains other elements, and my understanding is that you want the thing to be a replacement for a pseudo-element, not a container for it? > > Depending on how this turns out (see below) I'd rather use a new element or something (like `<pseudo>` or what not), but haven't thought too deep about it... Fair enough > > There are various questions that come up with this, specially regarding generated content... Not necessarily unsolvable tho: > > * What happens if the slot is not in the right position in the DOM (e.g. `<div><slot name="::after"></slot><slot name="::before"></slot></div>`)? Do we just let it be? When queried from DOM (e.g. `nextSibling`) it would behave like regular DOM, and for render/layout it would behave like the pseudo-element. > * What if the `<slot>` has children? Do those get rendered? Only if there's no content like in shadow dom? Probably not rendered at all, but it does raise the question of whether this should be like a self-closing new element. > * What if the pseudo-element would not be generated, e.g. `content: none`, or `::marker` on something that's not a list-item, or `::backdrop` for something that's not in the top layer? Do we just suppress boxes of the slot, or do we actually honor the `display` property? Probably honor `display` and have it set to none by the UA? > * Dynamic mutations here seem kinda tricky, depending on how we answer some of these questions. > * The contents of `::before` / `::after` are not exposed to author code, and they need some magic (like images that load the content property at a given index or so). Would we expose those to authors? If so we need to define how that would work... Could be cool as a future thing to expose a content getter. > For generated content, the `<slot>` is interesting _if_ it would match the `::before` / `::after` rules. Then, in a way, you're just changing the container you're stuffing the generated content into, which is kinda what slot does in Shadow DOM if you squint enough? Behavior is a bit different (`display: contents` rather than inline for the box or so), but the model is reasonable I think... > I think `::backdrop` and `::view-transition-*` etc are more interesting than `::before` / `::after`. If you have a slot for `::before` / `::after` you might as well have it as a regular element to begin with. Where you'd want to proxy the pseudo-element is when: 1. the pseudo-element behavior is defined by the spec, and perhaps difficult to mimic with a regular element 2. you want the pseudo-element to exist/be rendered regardless of whether you have a DOM element for it. > The more I think about it the more I think it can work and be a nice model for these pseudos, actually... You just don't generate anonymous elements for these things, and reuse the existing DOM element. Not sure I understand? > Something to think about, even though I'm not sure there are use cases for these, is what to do about elements that are "leafs" like `<input>`, you can't just do `<slot name="::placeholder">` in there... But also it doesn't make sense to listen to events from a `::placeholder` so perhaps it's OK? Also in the future we can have a corresponding `for` attribute where the target element is a ref rather than the parent. -- GitHub Notification of comment by noamr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12575#issuecomment-3159728560 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 6 August 2025 11:14:21 UTC