Content Mirrors

[jonathantneal]

While discussing #571, there has surfaced a need to mirror another element.

In #571, to mirror another element is to render some node in another context, like a shadow tree, while being able to retain the contents, styles, or even interactivity of the original. This is similar to slotting content, only without the restrictions of only being able to slot child nodes.

Another quality of a mirror comes out of the implementation of #571, which is that the element is ‘moved’ into the shadow tree without removing the original node from the light dom. This is a kind of deep cloning, similar to what we do with an svg <use> element. This implies that a mirror of an element can exist in more than one place.

Possible Features:

• Allows content to render in more than one place. (closest parity is <use>, <foreignObject> and <svg:use> w3c/svgwg#511).
• Allows “clone”-like elements access to source events. (closest parity is the proposed getEventListeners(), [Proposal] Add EventTarget.getEventListeners() whatwg/dom#412)
• Allows deep slotting. (no known parity, [Shadow] Slotting indirect children WICG/webcomponents#574)

There is an existing proposal for a <mirror> element that may address these needs.

whatwg/html#6507

Would we consider picking it up to move forward as a feature for the web?

This mirroring functionality has seemed very helpful and sometimes necessary to me when building components like custom previews, selects, progressive enhancement wrappers, trees, tables, and multitracks.

Additionally, it seems like we would want some intuitive way for authors to opt-out of specific aspects of mirroring.

Very loosely, this kind of functionality seems possible by cloning a DOM tree and mirroring it with a MutationObserver. However, this will not allow the user to mirror events or styles.

This functionality also raises issues that I do not yet intuit good answers for.

• What exactly is shared in mirrors?
  • If I have a hovering effect on a mirroring source element, does that affect apply to the mirrored clone element, or vice versa, or is it something that I should configure?
  • If I have events on a mirroring source element, are those events applied to the mirrored clone, or vice versa, or is it something that I should configure?

Is this something we could pick up?

[bkardell]

Yeah, I also asked a similar question and mentioned mirror a few calls ago... It might be good to see if we could flesh out something better of a proposal/explainer that the group (including implementers) feels are reasonable and resubmit it to the issue. It seems appropriate enough to me to break out some little task force at least as it is potentially useful to a number of components - maybe it winds up being it's own wicg thing even... Definitely worth discussing though, imo.

[yinonov]

please do! it is extremly useful with documentation referencing
whatwg/html#8287

[css-meeting-bot]

The Open UI Community Group just discussed Content Mirrors.

The full IRC log of that discussion

<gregwhitworth> Topic: Content Mirrors
<gregwhitworth> github: https://github.com//issues/616
<gregwhitworth> JonathanNeal: *checks notes*
<gregwhitworth> JonathanNeal: what I want to say is that at this stage I'm looking for to get feedback into the issue as I have open questions
<gregwhitworth> JonathanNeal: it's about the way in which content is exposed in the shadow dom that is similar to slotting but involves what I'd call, advanced slotting
<gregwhitworth> JonathanNeal: what that looks like is this, there are different scenarios that get conflated
<gregwhitworth> JonathanNeal: we have a selectlist and when you open the item you can see the selected item in the top of the list, but in the popover of the items you will also see the item. It's being represented in two places at once
<gregwhitworth> JonathanNeal: we can copy the content, transfer innerText, etc
<gregwhitworth> JonathanNeal: there are areas where we need to "mirror" the content and it's painting the element much like the CSS property
<gregwhitworth> JonathanNeal: it may respond to events, it may not respond
<gregwhitworth> JonathanNeal: another scenario was for indirect slotting, I had a multitrack such as in Garageband or something like that
<gregwhitworth> JonathanNeal: you have a track, and a track after that - if you have a child track you would show it as a sibling but you show it as a child of it
<gregwhitworth> JonathanNeal: both of these fealt like a situation where I wanted to use content in a different place which is like slotting but not quite the same
<masonf> q+
<gregwhitworth> ack masonf
<gregwhitworth> masonf: you've been talking about it as slotting? It's only about shadow DOM, or is it able to mirror anything from anywhere?
<jhey> Howdy!
<gregwhitworth> JonathanNeal: I have tried to scope it there, but that's a good question
<jhey> Which issue are we talking about?
<jhey> #616 :D
<gregwhitworth> JonathanNeal: the SVG use element - it represents a kind of copy of something; does that clarify that it's not limiting it but it's not trying to work on everything
<gregwhitworth> JonathanNeal: I can see it working on other things
<gregwhitworth> masonf: interesting side note, use element uses shadow DOM
<gregwhitworth> masonf: in your track example, there is an imperative slotting API - it only works on the direct element but there has been a push to allow you to be able to slot into any slot element
<gregwhitworth> masonf: that's a much lighter weight thing than cloning and mirroring content
<gregwhitworth> JonathanNeal: in that situation, I reached for that; I don't mind the JS requirement, happy to hear that
<gregwhitworth> gregwhitworth: key ask is to review the proposal, add use cases and whether we should try and solve these problems but not committed to the solution
<JonathanNeal> I can scribe again :)
<gregwhitworth> JonathanNeal: yes, this is at Stage 0

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[bkardell]

I'd still like this, but it is "stage 0" and also has a similar open issue in HTML... I believe the main 'question' here is more to implementers than anything else, right? Do we need to keep this open, or can we close it and ask people to comment on 6507?

[bkardell]

We decided on the call today to close this