Re: [WICG/webcomponents] Form-associated custom elements: being a submit button (#814)

bahrus left a comment (WICG/webcomponents#814)

> Across Windows, Apple, Android, Qt, GTK, and major game engines, platforms provide a first-class, attachable behavior mechanism. It scales from simple gestures to complex coordination (scroll/collapse, physics, drag/drop) without subclassing or wrapping. The web would benefit from a similarly composable, declarative “attach behavior to an existing element” capability, orthogonal to frameworks, so authors can add interaction/semantics to any DOM node with clear lifecycle, cleanup, and encapsulation.

This sounds really great, thanks for clarifying.

Many of those solutions came after the origin of the web, and perhaps adopted their approach partly inspired from lessons learned from the web.  I wonder how much the restriction not to break anything constrains our ability to take a similar approach?  I do think it is worth considering, and I withdraw my initial negative reaction.  Maybe this is a good time for a gentle course correction moving in that direction?

An interesting question (to me) is:  Are there use cases where we would want to enable developers to enable one built-in behavior onto another built-in element that doesn't support that built-in behavior currently?  I suspect there are some (giving the hyperlink form like behaviors, maybe?), but I wonder if they are all short lived -- if there's a compelling case to cross pollinate such behaviors, why wouldn't the platform do so?  On the other hand, given that the platform moves at a rather slow pace, giving developers that ability to do that in the interim could be useful, especially considering Keynes's views on "long run" considerations.

But to be concrete as far as [this proposal(https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ElementInternalsType/explainer.md), the proposal mentions:

> This example shows how to configure the commandForElement and command properties imperatively:

```JavaScript
class CustomButton extends HTMLElement {
    static buttonActivationBehaviors = true;

    constructor() {
        super();
        this.internals_ = this.attachInternals();
    }

    get commandForElement() {
        return this.internals_.commandForElement ?? null;
    }

    set commandForElement(element) {
        this.internals_.commandForElement = element;
    }

    get command() {
        return this.internals_.command ?? '';
    }

    set command(value) {
        this.internals_.command = value;
    }
}
customElements.define('custom-button', CustomButton);
```

```html
<custom-button id="my-button">Open Dialog</custom-button>
<dialog id="my-dialog">Dialog content</dialog>

<script>
  const button = document.getElementById('my-button');
  const dialog = document.getElementById('my-dialog');

  button.commandForElement = dialog;
  button.command = 'show-modal';
</script>
```

It is almost a forgone conclusion that this proposal as it stands will spawn widely used mixins that implements command functionality, so I can definitely see the appeal of standardizing such mixins.

I don't know how far along we are in finalizing the command api.  Maybe in retrospect, it would have been better to make the built in button to have namespaced all the command functionality together:

```
oButton.behaviors.command.name = 'show-modal';
oButton.behaviors.command.forElement = dialog;
```

... which would  seemingly have allowed for more flexibility as far as sliding in functionality, and make the behavior / composable (?) approach more viable?

Perhaps this could still be done -- be able to reference the command property buttons at the top level for simplicity / backwards compability, but *also* via the more structured, namespaced way, and then we encourage or require that custom elements adopt the namespaced way as far as providing built in support (and look the other way if the developer also adds at the top level). 

Those are my confused, 2-cents(ical) thoughts.



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

Message ID: <WICG/webcomponents/issues/814/3393462400@github.com>