Re: [WICG/webcomponents] Reference Target "phase 2": seeking feedback and use cases (Issue #1111)

trusktr left a comment (WICG/webcomponents#1111)

> > an element contains more than one input in its shadow DOM. Being able to refer to only one input is impractical.
> 
> [@trusktr](https://github.com/trusktr) is this referring to some kind of composite control? Like, maybe a N part color input (R, G, B, A) or like something that might normally be in a fieldset, like a Postal Address?

Yeah, multiple elements in the shadow root.

Here's an example of something that currently works:

```js
<button commandFor="pets" command="show-modal">Open pets</button>
<button commandFor="cars" command="show-modal">Open cars</button>

<dialog id="pets">
 <p>...pets...</p>
 <button commandFor="pets" command="close">Close</button>
</dialog>

<dialog id="cars">
 <p>...cars...</p>
 <button commandFor="cars" command="close">Close</button>
</dialog>
```

[CodePen example](https://codepen.io/trusktr/pen/KwVRrXm)

Now in the next example, for whatever reason, the user may be organizing their code with custom elements. The purpose is not necessarily to publish a library of elements for other people, but to merely use custom elements as convenient containers for various purposes. In the following example, things don't work as "expected", with no convenient solution:

```html
<button commandFor="pets" command="show-modal">Open pets</button>
<button commandFor="cars" command="show-modal">Open cars</button>

<my-element></my-element>
```
```js
class MyElement extends HTMLElement {
 static { customElements.define('my-element', this) }

 constructor() {
  super()
  this.attachShadow({mode: 'open'})
  
  this.shadowRoot.innerHTML = `
   <dialog id="pets">
    <p>...pets...</p>
    <button commandFor="pets" command="close">Close</button>
   </dialog>

   <dialog id="cars">
    <p>...cars...</p>
    <button commandFor="cars" command="close">Close</button>
   </dialog>
  `
 }
}
```

[CodePen example](https://codepen.io/trusktr/pen/YPwLRrb)

Historically the DOM was never closed like this (if native internals were, users didn't know), and mainstream frameworks (React/Solid/Vue/Svelte/etc) don't have this sort of issue because they output everything in the top-level DOM. So when people try to migrate to Custom Elements, especially from other mainstream frameworks, they can encounter issues like this that can appear in an undesirable light.

> How would you like authors to be able to refer to the separate inputs?

I also have the question.

One issue with custom elements built with ShadowDOM is that (some) authors have to worry about exposing everything so that end users can choose what they want to freely configure. I personally am a fan of concepts or desires like [Open Stylable](https://github.com/WICG/webcomponents/issues/1052) and users being able to easily customize the (shadow) DOM. We all try to follow best practices, but sometimes, we just need freedom to modify something in a shadow and move along.

So, from that perspective, the idea that simply organizing into a native container (instead of using React/etc) puts up a barrier can be inconvenient.

What if the solution is related to the `part` API, as that's already a way to expose parts to the outside (still means the author has to care to expose parts, so sometimes users can still feel stuck when using 3rd-party libs)? For example, in the following hypothetical example the user can reference by ID and part:

```html
<button commandFor="myel:pets" command="show-modal">Open pets</button>
<button commandFor="myel:cars" command="show-modal">Open cars</button>

<my-element id="myel"></my-element>
```
```js
class MyElement extends HTMLElement {
 static { customElements.define('my-element', this) }

 constructor() {
  super()
  this.attachShadow({mode: 'open'})
  
  this.shadowRoot.innerHTML = `
   <dialog part="pets">
    <p>...pets...</p>
    <button commandFor="pets" command="close">Close</button>
   </dialog>

   <dialog part="cars">
    <p>...cars...</p>
    <button commandFor="cars" command="close">Close</button>
   </dialog>
  `
 }
}
```

Or, what if referenceTarget is unique to the element that is doing the targetting? In the following hypothetical example, the `referenceTarget` is on the element that is *pointing* to the target. The combination of `referenceTarget` and `commandFor` makes it access the part in the shadow of my-element. The idea is, each items that is doing the targetting, has the opportunity to specify exactly what to target, rather than the barrier (the custom element) having a single targettable item:

```html
<button commandFor="pets" referenceTarget="myel" command="show-modal">Open pets</button>
<button commandFor="cars" referenceTarget="myel" command="show-modal">Open cars</button>

<my-element id="myel"></my-element>
```
```js
class MyElement extends HTMLElement {
 static { customElements.define('my-element', this) }

 constructor() {
  super()
  this.attachShadow({mode: 'open'})
  
  this.shadowRoot.innerHTML = `
   <dialog part="pets">
    <p>...pets...</p>
    <button commandFor="pets" command="close">Close</button>
   </dialog>

   <dialog part="cars">
    <p>...cars...</p>
    <button commandFor="cars" command="close">Close</button>
   </dialog>
  `
 }
}
```

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/1111#issuecomment-3444739544
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/1111/3444739544@github.com>