- From: Lea Verou <notifications@github.com>
- Date: Mon, 04 Nov 2024 09:01:58 -0800
- To: WICG/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <WICG/webcomponents/issues/1029/2455238153@github.com>
Btw in case it's useful, I just did some research on existing native props, and I'm now less optimistic that we can carve out a path for prefixes that still allows reflection into native-like props: https://codepen.io/leaverou/pen/mdNjGod?editors=0110 In Chrome at least, there are 102 distinct prefixes, with 2 prefixes being 1 character long (`t`, `v`) and 6 prefixes that are 2 characters long (`ad`, `bg`, `ch``is`, `no`, `to`). ---- I’m on board with leaving the ergonomics up to userland to help unblock this. As long as we don't paint ourselves into a corner and are able to improve ergonomics later. Basically, the MVP is: - a way to register custom attributes as classes and associate them with certain tags and/or interfaces. - lifecycle hooks Something like: ```js HTMLElement.customAttributes.define("foo-title", class FooTitle extends Attribute { ... }); HTMLVideoElement.customAttributes.define("start-at", class StartAtAttribute extends Attribute { ... }); ``` With a custom attribute being defined on a superclass being available in all subclasses (so defining it on `HTMLElement` makes it availble on all custom elements too). Though do public properties and methods on these classes become element properties and methods? If so, that could increase concerns about clashes. I.e. do these classes basically become HTMLElement mixins? If so, TC39 folks could push back as this could be seen as encroaching on existing TC39 work on class mixins. -- Reply to this email directly or view it on GitHub: https://github.com/WICG/webcomponents/issues/1029#issuecomment-2455238153 You are receiving this because you are subscribed to this thread. Message ID: <WICG/webcomponents/issues/1029/2455238153@github.com>
Received on Monday, 4 November 2024 17:02:02 UTC