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

Re: Custom element design with ES6 classes and Element constructors

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 12 Jan 2015 09:20:03 -0800
Message-ID: <CAAWBYDD_LHivhKNE+G4pj9SVsdvgZ9RafbxaTt3PSvLRZ0rReQ@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Domenic Denicola <d@domenic.me>, WebApps WG <public-webapps@w3.org>
On Mon, Jan 12, 2015 at 5:16 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Sun, Jan 11, 2015 at 9:13 PM, Domenic Denicola <d@domenic.me> wrote:
>> However, I don't understand how to make it work for upgraded elements at all
> Yes, upgrading is the problem. There's two strategies as far as I can
> tell to maintain a sane class design:
> 1) There is no upgrading. We synchronously invoke the correct
> constructor. I've been trying to figure out the drawbacks, but I can't
> find the set of mutation events problems that relates to this. One
> obvious drawback is needing to have all the code in place so you might
> need a way to delay the parser (return of synchronous <script>
> loading).

That's the issue - you have to have all custom element definitions
loaded before any of your app is allowed to load, or else you'll have
confusing errors where your elements just don't work, or work in racy
conditions because you're racing an async script download against the
download+parse of the rest of the document.

> 2) As you indicate, upgrading becomes replacing. This used to be the
> old model and got eventually killed through
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21063 though there's no
> clear summary as to why that happened. Issues seem to be: mutation
> observer spam, dangling references, attributes, event listeners.

Yeah, as you say, this is also likely to be racy and bug-prone -
sometimes your events stick around (because the script that set them
ran after the script that initialized the element) and sometimes they
don't (because the race went the other way).  Even in the lack of
races, more non-obvious ordering constraints are confusing to authors.

> Forever prototype munging seems really broken too so we should really
> revisit these two approaches to custom elements I think.

Proto munging isn't even that big of a deal. It's the back-end stuff
that's kinda-proto but doesn't munge that's the problem.  This is
potentially fixable if we can migrate more elements out into JS space.

Received on Monday, 12 January 2015 17:20:50 UTC

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