- From: Daniel Buchner <daniel@mozilla.com>
- Date: Wed, 17 Apr 2013 15:59:08 -0700
- To: Rick Waldron <waldron.rick@gmail.com>
- Cc: Dimitri Glazkov <dglazkov@google.com>, public-webapps <public-webapps@w3.org>, Scott Miles <sjmiles@google.com>, Erik Arvidsson <arv@chromium.org>, Allen Wirfs-Brock <allen@wirfs-brock.com>
- Message-ID: <CAHZ6zJGTw6TXLERbJJ0OBOEfEAyWsuVetjuzqBU-RKYLORUGkg@mail.gmail.com>
*"This is just a repackaging of Object.defineProperties( target, PropertyDescriptors ) thats slightly less obvious because the target appears to be a string." * Is another difference that the 'x-foo' doesn't have to be 'known' yet? It seems to be a bit more than a repack of Object.defineProperties to me. On Wed, Apr 17, 2013 at 3:53 PM, Rick Waldron <waldron.rick@gmail.com>wrote: > > > > On Wed, Apr 17, 2013 at 6:16 PM, Dimitri Glazkov <dglazkov@google.com>wrote: > >> 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: >> > > The are called Property Descriptors. > > > >> >> HTMLElementElement.define('x-foo', { >> erhmahgerd: { writable: false, value: "BOOKS!" } >> }); >> >> > This is just a repackaging of Object.defineProperties( target, > PropertyDescriptors ) thats slightly less obvious because the target > appears to be a string. > > > Rick > > > > > >> 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 23:00:06 UTC