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

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

From: Dimitri Glazkov <dglazkov@google.com>
Date: Mon, 18 Feb 2013 12:47:15 -0800
Message-ID: <CADh5Ky1q8f9WMawpDHdoEENkW8GS23j5mBCq+JYaFn-HaRpR8Q@mail.gmail.com>
To: Daniel Buchner <daniel@mozilla.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, public-webapps <public-webapps@w3.org>, Scott Miles <sjmiles@google.com>, Erik Arvidsson <arv@chromium.org>, Boris Zbarsky <bzbarsky@mit.edu>
On Fri, Feb 15, 2013 at 8:42 AM, Daniel Buchner <daniel@mozilla.com> wrote:
> I'm not sure I buy the idea that "two ways of doing the same thing does not
> seem like a good approach" - the web platform's imperative and declarative
> duality is, by nature, two-way. Having two methods or an option that takes
> multiple input types is not an empirical negative, you may argue it is an
> ugly pattern, but that is largely subjective.

For what it's worth, I totally agree with Anne that two-prong API is a
huge wart and I feel shame for proposing it. But I would rather feel
shame than waiting for Godot.

>
> Is this an accurate summary of what we're looking at for possible solutions?
> If so, can we at least get a decision on whether or not _this_ route is
> acceptable?
>
> FOO_CONSTRUCTOR = document.register(‘x-foo’, {
>   prototype: ELEMENT_PROTOTYPE,
>   lifecycle: {
>      created: CALLBACK
>   }
> });

I will spec this first.

>
> FOO_CONSTRUCTOR = document.register(‘x-foo’, {
>   constructor: FOO_CONSTRUCTOR
> });
>

When we have implementers who can handle it, I'll spec that.

Eventually, we'll work to deprecate the first approach.

One thing that Scott suggested recently is that the second API variant
always returns undefined, to better separate the two APIs and their
usage patterns.

:DG<
Received on Monday, 18 February 2013 20:47:43 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:57 GMT