- From: Rick Waldron <waldron.rick@gmail.com>
- Date: Wed, 17 Apr 2013 19:11:30 -0400
- To: Daniel Buchner <daniel@mozilla.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: <CAHfnhfrc5pzTaEu91uhvxtHxpQvJZPWUzD_+_+eMuVzLVbAabA@mail.gmail.com>
On Wed, Apr 17, 2013 at 6:59 PM, Daniel Buchner <daniel@mozilla.com> wrote: > *"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. > > I'm sorry if I was unclear, but my comments weren't subjective, nor was I looking for feedback. Looks like Dimitri agrees: http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0306.html Rick > > > 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:12:17 UTC