Re: [w3ctag/design-reviews] HTML General Review: Custom Elements (#244)

Hey all,

Thanks for the links to the relevant discussion, @chaals. Spirited!

We had a pretty long conversation about this in today's call. 

In general, it seems we're constrained in our ability to provide guidance as this horse has been out of the barn for a few years. We don't have strong data for potential collision as-yet, but the TAG will be sure to encourage feature designers proposing new attributes to collect that sort of data to look for conflicts in future.

Anecdotally, it seems many element authors are going without prefixes. Here's a random set from webcomponents.org that include attributes:

- https://www.webcomponents.org/element/auto-check-element
- https://www.webcomponents.org/element/moduware/morph-button/v0.0.4-alpha
- https://vaadin.com/components/vaadin-dialog/html-api/elements/Vaadin.DialogElement
- http://ui.developers.brightspace.com/components/page-load-progress/
- https://www.webcomponents.org/element/tangy-form/elements/tangy-gps

The core issue is that the platform acts like a framework for running elements in a lifecycle they do not fully control, potentially processing attributes "behind" the back of a custom element. @plinss brings up the case of something like `style` or `class` which is processed in a high-frequency way. If a `newskoolstyle` global attribute were added and if it affected style or layout, and if a custom element already used such a value using a syntax that was somehow compatible (likely for booleans), the system may choose to do things the element author didn't want or anticipate.

Prefixing is one solution, ensuring that developers tell the system "don't use this, it's not for you", but it doesn't appear we'll be able to normatively restrict unprefixed attributes at this late date.

Other solutions are less complete. One could imagine a method which Custom Elements can invoke from their constructors to inform the system about "owned" attributes, preventing the system from using them for internal processing, treating them as "inert". Used defensively this would keep new HTML additions from breaking existing behavior. There's a fly in this ointment with regards to un-upgraded elements and it isn't clear what to do in those cases.

The best advice that we feel we can currently give is that HTML spec editors should only add global, side-effecting attributes after extensive study of the ecosystem to minimize breakage. Prefixing does not seem possible, but data would be a valuable contribution.

/cc @LeaVerou @annevk @domenic 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/244#issuecomment-414800951