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

I feel I've already tackled most of the complexities with CEs but am willing to open that can of worms again.

The current approach I've [implemented](https://github.com/clshortfuse/materialdesignweb/tree/933aebbc655981883f2046e867f179de1c58e1b6/mixins) is `mixins`. The idea is to replicate/extend the *native* feature. Meaning `<x-input>` does everything `<input>` does. There's no relearning how to do things for one CE provider and then another being different. 

That said, it's a pain to scaffold, but it works. And I know it works because I run over 1000 W3C spec [tests](https://github.com/clshortfuse/materialdesignweb/blob/933aebbc655981883f2046e867f179de1c58e1b6/test/spec/Button.test.js) to confirm. (Even fixing out-of-spec issues in Safari for `HTMLInputElement`).

But no beginner creating `MyFirstCheckbox` should have to deal with all the quirks. And there are many.

Some attributes aren't bidirectional with what's in the DOM. For example:

* `.value` is a `DOMString` which handles `null` differently.
* Attribute names and properties aren't symmetrical either. 99% it's fine, but sometimes it's `[max-length]`/`maxlength` not following common hyphenated uppercase.
* Some properties are so asymmetrical they related to very different properties (`[checked]/`defaultChecked`)
* Some attributes have hidden internal writes (`.checked` affects `.#checkedness`).
* Some properties have hidden translation layers (eg: form reset effects, checked, default checked).

If there's no parity with `.myProperty` and all that has to be scripted separately, that's fine, but I think people would prefer to set both at once. My strategy is properties (even internal) that can have attributes, not attributes that can have properties. Though, I can imagine building `class ReflectedAttribute extends Attr` couldn't be too hard.

I prefer overloading the native attributes names and properties names, but being forced to use custom is fine. I prefer being able to swap `HTMLButtonElement` with `XButtonElement` and change nothing else in code, but it's not a tradeoff for me. (And change 0 JS if you are using `.getElementById()` by hotswapping the tagname in HTML.) But that's me.

Attributes emitting events sounds good. Performance concerns versus `.defineProperties()` can be examined later. If the `Attr` can inspect the element it belongs to, which is likely (tagname or ownerNode, IIRC) then it should be enough to replicate Class hierarchy by means of `.stopImmediatePropagation`. For example, you may want most Attributes to work the same on all elements, but carve out exceptions for some. (eg: `<textarea>` handles `value` differently than `<input>`.)

Typing is always a mess. I do have some automatic, no transcompile needed, support for Typescript but the parser is rather subpar when working with pure JS files. I do feel once something become native in the browser, TS team will do what needs to be parse it right. There is very limited support for any of our adhoc Attribute/Property solutions. I've tried and resigned to not bother expecting JS structures to get first-class support. I'm not interested in writing once in JS and the again in a `d.ts` for each of my custom elements. I've accepted the limitations and found suitable workarounds.

I'll have to deepdive later into what other attributes can prove problematic, but this proposal just hit my radar, and wanted to add my concerns from experience dealing with CE/FACE.



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

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