[Bug 18596] [Custom]: Use a "has a" relationship instead of "is a" for custom types

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18596

Dominic Cooney <dominicc@chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dominicc@chromium.org

--- Comment #1 from Dominic Cooney <dominicc@chromium.org> 2012-08-17 02:24:52 UTC ---
(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.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 17 August 2012 02:24:53 UTC