[css-pseudo-4] Using real DOM elements to proxy pseudo-elements

[noamr]

... OP Edited ...

This is an alternative idea to the many existing suggestions about improving access to pseudo-elements such as #12163.

The idea is that instead of figuring all kinds of different accessors to pseudo-elements, we would allow the author to create a real-DOM proxy for them, using a regular HTML element.

<menu>
  <>Menu content<>
  <span class=backdrop>
</menu>

<style>
  menu {
    .backdrop { display: pseudo-element(::backdrop); }
  }
</style>

The span element wouldn't render anything on its own, but would rather be a "reference" to a pseudo-element, the backdrop of the menu in this case.
This pseudo element is now available using querySelector or any other DOM APIs, it dispatches events in the normal way, it works with getComputedStyle and getBoundingClientRect(), and so forth. But rendering-wise, and also in terms o fUI events, it represents whatever the corresponding pseudo-element represents.

I think this would alleviate a lot of the issues raised about the pseudo-element specific JS APIs, though there are several things to be mindful around it.

Some notes:

• We would need a way to address an element that is not the parent, because some pseudo-elements can work on self-closing elements (e.g. img or input).

This could work something like this:

<section>
  <img class=thumb>
  <span class=error>
</section>

<style>
   img.thumb::after { pseudo-name: --error; }
  .error { display: pseudo-element(--error); } 
</style>

• Some proxy elements would represent multiple pseudo-elements, e.g. view-transition-group(*).
• There would need to be some JS accessors that reflect which pseudo-element was the target of an event and whether the target pseudo-element exists.

[tabatkins]

(Noam ran this by me before they posted it.)

I like this idea quite a bit! By having a real element, a lot of questions are automatically answered, and we reduce the necessary API surface a lot. It's also an explicit opt-in, so we don't have to worry about legacy behavior for, say, mouseover events. The remaining questions (like how to handle pseudo-elements with arguments, or ones with multiplicity) are already questions in need of answering, so this doesn't complicate things further than they already are, I think.

I think re-using slot in this way seems reasonable - it conceptually functions similarly to its role in shadow trees. I'd be okay if we had to invent a fresh element for it too, tho.

[astearns]

I’m worried about overloading the name attribute like this, as it’s not a 1-1 match for how it currently interacts with a matching slot attribute (and are there sites in the wild that already use "::backdrop" or whatever other pseudo-element names in slot name attributes?). I think I’d want to use a separate attribute on the <slot> element or a new element entirely.

And I think it’s a bit hacky to require markup changes in order to get script access to your pseudo-elements. But I suppose it might end up being less hacky than whatever compromises we’d have to make in a more direct scripting solution.

[noamr]

I’m worried about overloading the name attribute like this, as it’s not a 1-1 match for how it currently interacts with a matching slot attribute (and are there sites in the wild that already use "::backdrop" or whatever other pseudo-element names in slot name attributes?). I think I’d want to use a separate attribute on the <slot> element or a new element entirely.

In many ways slot has a similar semantic meaning to this, as it is a proxy/placeholder to a different thing, but having a more explicit attribute works for me. I doubt that web compat is an issue though.

[emilio]

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...

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?

• What if the <slot> has children? Do those get rendered? Only if there's no content like in shadow dom?

• 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?

• 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...

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...

For other pseudo-elements like ::backdrop and so on tho, you really want the ::backdrop box to be the <slot>s, and you don't care about the contents (because ::backdrop has no contents)... So the <slot> metaphor breaks there a little bit (and I think that's why I'd prefer a new element).

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.

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...

[noamr]

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.

[emilio]

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.

Hmm, not sure I agree? It seems like a pretty strong use case to want mouse events for ::before and ::after? Indeed ::scroll-marker pseudos are very similar to ::before / ::after in this regard, aren't they?

[noamr]

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.

Hmm, not sure I agree? It seems like a pretty strong use case to want mouse events for ::before and ::after? Indeed ::scroll-marker pseudos are very similar to ::before / ::after in this regard, aren't they?

Yea fair

[Loirooriol]

what to do about elements that are "leafs"

Presumably you could still use this by inserting the <slot> (or whatever) using DOM APIs (or writing markup in XHTML)?

[noamr]

what to do about elements that are "leafs"

Presumably you could still use this by inserting the <slot> (or whatever) using DOM APIs (or writing markup in XHTML)?

We don't want to introduce new web platform features that rely on the ability to create invalid HTML using JS :)

[danielsakhapov]

A few questions:

• I'll cite @flackr from How to handle addEventListener on CSSPseudoElement? #12163 (comment):

Not all pseudo-elements are trivially replaced with real elements. There are many use cases where they are dynamically generated, even according to layout as in the carousel use case where you get a ::column::scroll-marker for each page of content which depends on the layout of the box (e.g. chrome.dev/carousel/horizontal/pages, codepen.io/flackr/pen/yLmyPEV). Developers cannot simply provide real elements because they don't know how many or which items are in each column.

Probably fixable by introducing an index to ::column though. But what if there will be more pseudos like that?

• Will there be a way to understand that the pseudo "exists"? For CSSPseudoElement there is a plan for Add a property to the CSSPseudoElement IDL interface to determine if a pseudo element "exists" #12158.