New test: libraries should offer control over setting attributes vs JS properties

[trusktr]

Now that React 19 is coming out, it will finally have better support for Custom Elements, but it is still not as good as it could be.

• RFC: Plan for custom element attributes/properties in React 19 facebook/react#11347

Specifically see this reply to the OP: facebook/react#11347 (comment)

What custom-elements-everywhere is missing is a test to verify that each library gives users control over setting DOM attributes vs JS properties.

Lit's html template tag has syntax for this. For example,

• foo=${value} sets the foo attribute
• .foo=${value} sets the .foo JS property
• ?foo=${value} toggles the existence of the foo attribute based on the Boolean value

Similarly, Solid.js JSX has the following syntax:

• foo={value} is dynamic, it sets the foo attribute on a non-custom element (no hyphen in name) or the foo JS property in a custom element (there are reasons for this)
• prop:foo={value} always sets the foo JS property
• attr:foo={value} always sets the foo attribute
• it does not have a special Boolean attribute syntax, custom elements are expected to handle the Boolean value in the JS property (or a stringified boolean if value is passed as an attribute)

Solid's html has similar syntax (but with ${} interpolations)

Pota's html supports both Solid and Lit syntax.

Etc.

---

This is not just a nice to have, this is a necessity. We cannot guarantee custom elements are written a certain way.

• some elements accept attributes only
• some accept JS properties only
• some accept both
• some accept a mix
• some authors rely on attributes for styling :host with attribute selector
• some users want to set an attribute for styling from the outside (they could set the JS prop, and the element would work, but their CSS would not be able to select the element)
• etc

It is impossible for any templating system could heuristically guess if something should be set as attribute or as property (I.e. to guess the CE author's or CE user's intent). Template systems could have defaults (like the above do), but ultimately the user needs control, and authors also need control on telling users how to use their custom elements regardless of how frameworks work.

[mrginglymus]

I've added a PR here demonstrating (one of the many) issues with react's implementation - it's actually regressed from react 18, for support for what is a fairly bare-bones custom element: #2466

I have written a suite of custom elements largely for use where a reactive framework is inappropriate, so it's only moderately annoying to have react 19 not work with them, but it's quite surprising nonetheless.

[trusktr]

Yay! Nice you got something going on this @mrginglymus!