Re: [WICG/webcomponents] Proposal: Custom attributes for all elements, enhancements for more complex use cases (Issue #1029)

Hi @trusktr

I'm fine if you prefer to use separate custom element "element behaviors", essentially abandoning/undercutting the whole premise for our proposals (including yours), the moment we seemed to reach a consensus between us, annoying as that is 😄.  Go for it!

The good news is the platform has everything that you need already, other than perhaps a little more flexibility with some HTML tags, like the table tag, which I'm fine if the platform feels the need to address.

What I'm not so keen on is that the premise you seem to have for why the rest of us should all abandon wanting to enhance elements themselves, is that it doesn't play nice with current JSX, and a vague "that's not a direction JSX would go in".  I view JSX as a tool that is supposed to help us, not hinder us.  I just don't find that argument compelling.  And it seems to ignore the fact that countless frameworks/libraries, which I've linked to in my proposal, to which I may add elementjs, find it useful to want to enhance elements directly, including React, which adds "react fiber" objects to the elements themselves.  My proposal is attempting to "formalize" what the king of all JSX frameworks is doing already, in an interoperable way.

I feel like I'm on some infinite loop, spanning decades, of bringing up points already raised with the same cast of characters ( 😄 ), but anyway, the other reason I don't find that argument compelling, is that some JSX based libraries like SolidJS and Astro, *have* in fact started using attributes in the JSX to institute behavior like functionality:

```JSX
<For each={state.list} fallback={<div>Loading...</div>}>
  {(item) => <div>{item}</div>}
</For>
```

Why not carry over that concept to adorning built-in or custom elements?  If you don't like the bracket idea for grouping related properties and attributes together, maybe you prefer a common prefix approach? In the example above, focusing on the fallback attribute, solidjS is using curly braces to group things, rather than square brackets, as I suggested.  I didn't put much thought into which would be better, I couldn't care less between the two, maybe using curly braces is a direction JSX could go with?

In fact, for quite a while, I was following the path you appear to be on now, for example with [this approach](https://github.com/bahrus/pdpu).  I did struggle with the question, especially as I liked the way separate elements could allow the attributes to form "complete sentences" via boolean, prefix-less attributes.  And also, hoping that what the platform had already provided was sufficient, no need for requesting more.

But with time, I have evolved to think it is much better to group related things closer / more tightly  together.  I believe there are performance benefits.  Also, it is easier for copy/cut and paste, and also lends to a better api (especially when we want to combine multiple behaviors together for the same element):

```JS
myTRElement.enhancements.expander.isExpanded = true;
```

vs.

```JS
let myExpanderBehaviorIHope = myTRElement.firstChild;
while(!(myExpanderBehaviorIHope instanceOf MyExpanderBehavior)){
  myExpanderBehaviorIHope = myExpanderBehaviorIHope.nextElementSibling;
}
myExpanderBehaviorIHope.isExpanded = true;
```

Not to mention the ambiguity non experts using the library are likely to face:

>  Wait, does that element behavior apply to the parent, or the next element sibling, or the previous element sibling?  I'm confused.

Not all such element behaviors could be child elements.  For example, what if you want to enhance the input element, which would require more platform parsing adjustments, I think.  Just to placate one vision of where JSX ought to go?  



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

Message ID: <WICG/webcomponents/issues/1029/2112095413@github.com>

Received on Wednesday, 15 May 2024 10:06:33 UTC