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

clshortfuse left a comment (WICG/webcomponents#1029)

Seems there's some traffic on this recently, though I've been out of W3C stuff for the past year and missed some conclusions, so excuse if I'm reiterating point.

It seems from the Custom Element side there's no true real added functionality other than make using mixins less of a requirement for shared components. If the concept is shared attributes across multiple CEs then I haven't found a technical barrier because mixins and class extension have worked well enough.

If we're talking native elements that's pretty huge. The ability to, essentially, register a callback on any element that uses an attribute regardless of then being CEs has great potential.

From a theming perspective, sometimes CSS isn't enough so hooking into some sort of callback when an element receives an attribute would allow you to script some nice JS reliant effects and possibly even useful for polyfilling missing browser CSS features.

From a data-bind sense, it would be great to have an attribute trigger a callback when. I can envision tagging certain parts of a shadow root to possibly even to wire an event on attribute assignment and not need to walk the DOM/TemplateFragment to find where to bind an element. The attribute: `[x-bind=title]` would be huge for ease of custom elements wanting to bind to their children. (Though doesn't make text nodes easier but there's always `<span x-bind=body>`)

The main point discusses parsing lightly, but I would rather that not be part of the spec. There's way too many ways to deal with string parsing and while the performance obsessed side of me jump at browser based parsing (eg: in C) over via JS scripting, there's so many ways to parse a "number" it can't always be right (as null == 0, as integer only, as float). In core HTMLElements there a bunch of special rules and I would hate for the spec to be in the way of being able to replicate those rules over JS. The raw string and null if empty is enough, IMO. Abstraction can done on JS people want (eg: `Number.parseInt()`, `Number.parseFloat()`, etc).

As for how you relate attributes to properties, I feel that is also better out of scope. Sure it can easier to one-shot certain things, but from a technical side, it's not all that much better than a `WeakMap<HTMLElement, T>`. If people want to overload the prototype of an element that can be their own external thing. As you wireup an attribute callback for elements the author can choose to modify the prototype before that. If that sounds "difficult" some library author can bridge the ease of use gap for common patterns.

At its simplest, I'd just want some ```
defineCustomAttribute(kekabCaseAttr, (element, kebabCaseAttr, previousValue, newValue => { ... });
```

I don't see the need for requiring a class. It seems more to track. If you want to build a class, then having the registration function call a static function in that class is probably what I would do to make it more easily managed "under one roof", but I'm not sure why lifecycle should be tied to just tracking attribute tracking.

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

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