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)
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.
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.
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
htmltemplate tag has syntax for this. For example,foo=${value}sets thefooattribute.foo=${value}sets the.fooJS property?foo=${value}toggles the existence of thefooattribute based on the Boolean valueSimilarly, Solid.js JSX has the following syntax:
foo={value}is dynamic, it sets thefooattribute on a non-custom element (no hyphen in name) or thefooJS property in a custom element (there are reasons for this)prop:foo={value}always sets thefooJS propertyattr:foo={value}always sets thefooattributeSolid's
htmlhas similar syntax (but with${}interpolations)Pota's
htmlsupports 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.
:hostwith attribute selectorIt 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.