Re: Does JS bound to <element> need to inherit from HTMLElement?

I wonder if there may be a "cultural" difference involved in our different
points of view. As a C++ developer I think your point of view makes a lot
of sense.  As a JavaScript developer I find it puzzling.  Given a JS object
I can override its value getter and add new properties operating on the
object or inheriting from it.  Pre-ES6, the number of failure modes in both
paths loom large. Anyone looking at the end result won't be able to tell
the difference.

Anyway the group seems keen on inheritance so I hope it works out.


On Mon, Apr 15, 2013 at 11:24 PM, Dominic Cooney <dominicc@google.com>wrote:

> On Sat, Apr 13, 2013 at 12:03 PM, John J Barton <
> johnjbarton@johnjbarton.com> wrote:
>
>> While I completely understand the beauty of having any JS object bound to
>> an <element> inherit functions that make that object 'be an element', I'm
>> unsure of the practical value.
>>
>> To me the critical relationship between the JS and the element is JS
>> object access to its corresponding element instance without global
>> operations. That is, no document.querySelector() must be required, because
>> the result could depend upon the environment of the component instance.
>>
>
> The critical issue to me is that there is a canonical object that script
> uses to interact with the element. With ad-hoc wrapping of elements in
> JavaScript, there are two objects (the "native" element wrapper provided by
> the UA and the object provided by the page author) which results in tedium
> at best (I did querySelector, now I need to do some other step to find the
> author's wrapper if it exists) and bugs at worst (the author's wrapper is
> trying to maintain some abstraction but that is violated by direct access
> to the native element wrapper.)
>
>
>> Whether that access is through |this| is way down the list of critical
>> issues for me. Given a reference to the element I guess I can do everything
>> I want. In fact I believe the vast majority of the JS code used in
>> components will never override HTMLElement operations for the same reason
>> we rarely override Object operations.
>>
>
> The Object interface is not terribly specific and mostly dedicated to
> metaprogramming the object model, so it is not surprising that it isn't
> heavily overridden.
>
> Elements are more specific so overriding their operations seems more
> useful. If I design a new kind of form input, it's very useful to hook
> HTMLInputElement.value to do some de/serialization and checking.
>
> Extending HTMLElement et al is not just about overriding methods. It is
> also to let the component author define new properties alongside existing
> ones, as most HTMLElement subtypes do alongside HTMLElement's existing
> properties and methods. And to enable authors to do this in a way
> consistent with the way the UA does it, so authors using Web Components
> don't need to be constantly observant that some particular functionality is
> provided by the UA and some particular functionality is provided by
> libraries.
>
>
>> So is the inheritance thing really worth the effort? It seems to
>> complicate the component story as far as I can tell.
>>
>
> I think it is worth the effort.
>
> --
> <http://goto.google.com/dc-email-sla>
>