*"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.r...@gmail.com>wrote: > > > > On Wed, Apr 17, 2013 at 6:16 PM, Dimitri Glazkov <dglaz...@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< >> > >