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

RE: Custom element design with ES6 classes and Element constructors

From: Domenic Denicola <d@domenic.me>
Date: Wed, 28 Jan 2015 05:32:27 +0000
To: Elliott Sprehn <esprehn@google.com>
CC: Yehuda Katz <wycats@gmail.com>, Dimitri Glazkov <dglazkov@google.com>, Erik Arvidsson <arv@google.com>, Dmitry Lomov <dslomov@chromium.org>, "WebApps WG" <public-webapps@w3.org>
Message-ID: <CY1PR0501MB136937A09EEF4498CD311384DF330@CY1PR0501MB1369.namprd05.prod.outlook.com>
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 05:32:56 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:25 UTC