This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Perhaps this has been discussed before, but I think we could simplify custom elements significantly by creating a 'custom' property (or some similar name) on HTMLElement. This property would hold the instance of the created custom element type (and return null until the custom type was bound). E.g. instead of: elm.myCustomMethod() You get: elm.custom.myCustomMethod() This has a number of effects: 1. The concept of "upgrading" an element to a custom element no longer requires mutating the DOM tree or the prototype chain. 2. Makes it obvious whether or not a custom type has been bound (just check if elm.custom is truthy). 3. Eliminates the risk of custom APIs masking future, standardized DOM APIs. 4. Clearly indicates to the consumer of a component which APIs are custom vs. native.
(In reply to comment #0) > … This property would hold the instance of the created custom > element type (and return null until the custom type was bound). > > E.g. instead of: > > elm.myCustomMethod() > > You get: > > elm.custom.myCustomMethod() The proposal has benefits. But it has these downsides. The consumer must dereference custom. The consumer must recall, is the property they want on the DOM object? Or the custom object? The consumer must expect disappointment with this: var goodies = elm.custom; … enjoy goodies … document.body.appendChild(goodies); One logical element has been split in half. This has downsides for the component author too. What does 'this' refer to? Neither is the whole. So the component author must dereference. And recall, is the property they want on the custom object? Or the DOM object? There is no place to override behavior. You’re writing a timezone picker. The semantic element is <select>. Do you put a selectedIndex property on every instance? A prototype would have helped. > This has a number of effects: > > 1. The concept of "upgrading" an element to a custom element no longer requires > mutating the DOM tree or the prototype chain. Mutating the DOM tree makes me squeamish too. But it is the best choice. Mutating the prototype chain isn’t countenanced by either proposal. > 2. Makes it obvious whether or not a custom type has been bound (just check if > elm.custom is truthy). True. What about elm instanceof TimeZonePicker which makes it obvious whether elm has been bound, and to what. > 3. Eliminates the risk of custom APIs masking future, standardized DOM APIs. DOM already carries this risk. Did it materialize? Was it serious? > 4. Clearly indicates to the consumer of a component which APIs are custom vs. > native. It is a specious distinction. Native APIs can be replaced. The consumer values expediency.
We took the approach that closely matches how any DOM element (custom or not) is created.