- From: Dimitri Glazkov <dglazkov@google.com>
- Date: Wed, 17 Apr 2013 15:16:20 -0700
- To: public-webapps <public-webapps@w3.org>
- Cc: Scott Miles <sjmiles@google.com>, Daniel Buchner <daniel@mozilla.com>, Erik Arvidsson <arv@chromium.org>, Rick Waldron <waldron.rick@gmail.com>, Allen Wirfs-Brock <allen@wirfs-brock.com>
Inspired by Allen's and Scott's ideas in the "Benadryl" thread, I dug into understanding what <element> actually represents. It seems that the problem arises when we attempt to make <element> _be_ the document.register invocation, since that draws the line of when the declaration comes to existence (the registration line) and imposes overly restrictive constraints on what we can do with it. What if instead, the mental model of <element> was a statement of intent? In other words, it says: "Hey browser-thing, when the time is right, go ahead and register this custom element. kthxbai" In this model, the proverbial registration line isn't drawn until later (more on that in a moment), which means that both <element> and <script> can contribute to defining the same custom element. With that in mind, we take Scott's/Allen's excellent idea and twist it up a bit. We invent a HTMLElementElement.define method (name TBD), which takes two arguments: a custom element name, and an object. I know folks will cringe, but I am thinking of an Object.create properties object: HTMLElementElement.define('x-foo', { erhmahgerd: { writable: false, value: "BOOKS!" } }); When the registration line comes, the browser-thing matches <element> instances and supplied property objects by custom element names, uses them to create prototypes, and then calls document.register with respective custom element name and prototype as arguments. We now have a working declarative syntax that doesn't hack <script>, is ES6-module-friendly, and still lets Scott build his tacos. Sounds like a win to me. I wonder how Object.create properties object and Class syntax could mesh better. I am sure ES6 Classes peeps will have ideas here. So... When is the registration line? Clearly, by the time the parser finishes with the document, we're too late. We have several choices. We could draw the line for an element when its corresponding </element> is seen in document. This is not going to work for deferred scripts, but maybe that is ok. For <element>s that are imported, we have a nice delineation, since we explicitly process each import in order, so no problems there. What do you think? :DG<
Received on Wednesday, 17 April 2013 22:16:47 UTC