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

bahrus left a comment (WICG/webcomponents#814)

@justinfagnani Would it make sense to have the platform provide these mixins as an add-on, that leverages the more "micro" level, meticulous maneuverings as spelled out in the current proposal?  Or are you suggesting mixins *instead of* the [current proposal](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ElementInternalsType/explainer.md)?  I haven't done a deep dive, but my instinct leans towards favoring the former.

At the risk of side-tracking this thread:

@EisenbergEffect 

>  Can we please explore a more modern behavior-oriented design that not only solves the button behavior issue but via the same mechanism....

While I *think* we generally agree on the end goal, I think this statement concerns me a bit.  I think we should resist the temptation to try to find some "generalization" between these two very different problem spaces, especially if it results in confusing / clunky api's.  This thread is all about the developer "opting-in" to bring in behavior into a problem domain where the developer is in full control, and has basically no namespacing concerns to contend with.  

As opposed to many third party developers "piling on" behavior onto an existing element that doesn't want to opt in to anything.  These two problems are night-and-day, as far as I'm concerned.

Let me step through my thought process, for why I am explicitly proposing some subtle differences to what your example indicates, and perhaps you can point out why you (and everyone else, it seems) have seemingly dismissed [my proposal](https://github.com/WICG/webcomponents/issues/1000) as not being worth giving it the time of day.  Feel free to reply to my feedback here over there on that proposal so as not to hijack this thread.

The syntax:  

```JavaScript

export class MyBehavior extends HTMLBehavior {
  connectedCallback() { 
    // access to this.owner
  }

  disconnecteCallback() { 
    // access to this.owner
 }
}

customBehaviors.define("my-behavior", MyCustomBehavior);

```

```html
<div behaviors="my-behavior">Div with custom behavior applied.</div>
```

gives the developer the erroneous (I think?) impression that they can add public properties and  methods to the class, and access them from the top level of the element:

```JavaScript
oDiv.myProp = {some:Prop};
oDiv.doSomething();
```

In some hand wavy way, you could argue that these properties wouldn't get attached onto the top level of the button element until the attribute is added:

```html
<div behaviors="my-behavior">Div with custom behavior applied.</div>
```

But how would the platform avoid future clashes?  And between different developers? It's hard to wrap my brain around the platform defining a class, with properties and methods, but the moment the behaviors attribute is found, pretend that those properties and methods don't exist?

If this could be done, why wasn't it done with the "is" solution, just allow "is" to have multiple space delimited values?

I think it is important that we should allow the developer to add behavior onto the div element in a way that doesn't clash with the platform "after" the initial html renders, to support (progressive) enhancement.  The only way I could see this having a fighting chance of  working (again, maybe I'm missing something) is if the behavior must be set before parsing happens, and not after.  That seems too limiting, doesn't it?

And then there's the matter of requiring two attributes to do what most libraries like alpine and htmx can do with one:

```html
<div log-to-console="clicked on a div"></div>
```

Why make adoption harder, just to satisfy some desire to adopt a universal paradigm to both problem spaces?





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

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