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

RE: Minimum viable custom elements

From: Domenic Denicola <d@domenic.me>
Date: Thu, 15 Jan 2015 19:28:31 +0000
To: Dimitri Glazkov <dglazkov@google.com>, Anne van Kesteren <annevk@annevk.nl>
CC: Erik Arvidsson <arv@google.com>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps <public-webapps@w3.org>
Message-ID: <CY1PR0501MB13696DE5DE9583C96DFEBB1BDF4E0@CY1PR0501MB1369.namprd05.prod.outlook.com>
From: Dimitri Glazkov [mailto:dglazkov@google.com] 

> Why is "Not having identity at creation-time is currently a mismatch with the rest of the platform" a problem? Why does it all have to be consistent across the board? Are there any other platform objects that are created by HTML parser or a similar device?

In IRC we've been discussing how I don't think there's actually any (observable) mismatch with the rest of the platform if we are careful.

In particular, if we make it a rule that when parsing a given fragment, createdCallbacks run in registration order (not, say, in parse order), I think it works. Because then the built-in elements, which are (conceptually) registered first, go through the __proto__-munge + createdCallback() process first. Then, when the createdCallback() for any user-defined elements runs, all existing elements look to be already upgraded.

If we want createdCallbacks to run in parse order (which does seem probably better, although I'd be curious for concrete arguments why), then the only deviation required between custom and built-in elements is privileging the native elements with some ability to jump to the front the queue. Which seems pretty reasonable given that we already have lots of cases where custom elements do things sorta-async and native elements need to do things more synchronously. 

Received on Thursday, 15 January 2015 19:29:00 UTC

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