W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: Custom element design with ES6 classes and Element constructors

From: Yehuda Katz <wycats@gmail.com>
Date: Tue, 27 Jan 2015 22:03:13 -0800
Message-ID: <CAMFeDTVeHLV8g+jHgNghMEkL-o-Lt4pJXA4WmLhtGi=D+mMtYQ@mail.gmail.com>
To: Domenic Denicola <d@domenic.me>
Cc: Elliott Sprehn <esprehn@google.com>, Dimitri Glazkov <dglazkov@google.com>, Erik Arvidsson <arv@google.com>, Dmitry Lomov <dslomov@chromium.org>, WebApps WG <public-webapps@w3.org>
Agree with this completely.

Yehuda Katz
(ph) 718.877.1325

On Tue, Jan 27, 2015 at 9:32 PM, Domenic Denicola <d@domenic.me> wrote:

> From: Elliott Sprehn [mailto:esprehn@google.com]
> > Perhaps, but that logically boils down to "never use string properties
> ever" just in case some library conflicts with a different meaning. We'd
> have $[jQuery.find](...) and so on for plugins.
> Nah, it boils down to "don't use string properties for meta-programming
> hooks."
> > Or more concretely isn't the new DOM Element#find() method going to
> conflict with my <polymer-database>'s find() method? So why not make that
> [Element.find] so polymer never conflicts?
> You can overwrite methods on your prototype with no problem. The issue
> comes when the browser makes assumptions about what user-supplied methods
> (i.e., metaprogramming hooks) are supposed to behave like.
> More concretely, if there was browser code that *called*
> arbitraryElement.find(), then we'd be in a lot more trouble. But as-is
> we're not.
> (BTW find() was renamed to query(), IIRC because of conflicts with
> HTMLSelectElement or something?)
Received on Wednesday, 28 January 2015 06:04:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:43 UTC