- From: Daniel Buchner <daniel@mozilla.com>
- Date: Sat, 13 Apr 2013 22:08:34 -0700
- To: Scott Miles <sjmiles@google.com>
- Cc: William Chen <wchen@mozilla.com>, Rafael Weinstein <rafaelw@google.com>, Rick Waldron <waldron.rick@gmail.com>, John J Barton <johnjbarton@johnjbarton.com>, Dave Herman <dherman@mozilla.com>, Allen Wirfs-Brock <allen@wirfs-brock.com>, Boris Zbarsky <bzbarsky@mit.edu>, Jonas Sicking <jonas@sicking.cc>, Blake Kaplan <mrbkap@mozilla.com>, public-webapps <public-webapps@w3.org>, Steve Orvell <sorvell@google.com>, Dimitri Glazkov <dglazkov@google.com>
- Message-ID: <CAHZ6zJE5DquoR+UBuwrz8iBokGc37_h78Jg02M73Z_yofE_9xw@mail.gmail.com>
I agree with Scott, the linkage between <element>, <script>, and automatic document registration is hugely important. In fact, without this foundational linkage, the declarative API would be a jankified husk. On Apr 13, 2013 9:13 PM, "Scott Miles" <sjmiles@google.com> wrote: > >> I think if an element needs such custom behavior it should be required > to use a "constructor=" attribute to associate an app provided constructor > object with the element and > > I don't like this because it requires me to make a global symbol. > document.register, as you pointed out does not. In the original scenario, > the nesting of the <script> in the <element> provided the linkage between > them (however it played out), I hate to lose that. If you think this is a > bogus objection, please let me know (and I will take it seriously). > > >> the constructor should be specified in a normal <script> bock using > normal JS techniques. > > There is a practical problem that we cannot make a constructor using > 'normal' techniques that creates a DOM node, so sayeth the Gecko guys > (iirc). There was a suggestion to make the custom objects have-a node > instead of be-a node, which has many positives, but we tried that in > polyfills and the users revolted against 'this !== my-element-instance' > inside their class. > > > On Sat, Apr 13, 2013 at 7:16 PM, Allen Wirfs-Brock <allen@wirfs-brock.com>wrote: > >> >> On Apr 13, 2013, at 4:52 PM, Daniel Buchner wrote: >> >> @Rick - "This effectively implies that some "magic" global code is >> executed before any <element> nested <script> code." <-- if I had a bitcoin >> (pre-bubble pop, naturally) for every inference made in web programming, >> I'd be on a yacht in a sunny place. >> >> >> We probably shouldn't be too judgmental on what is or isn't "magic". >> Parsing HTML has lots of semantics associated with it (such as creating >> DOM elements and loading and evaluating script code, and, oh yeah, display >> rendering...) so adding new semantics for new elements isn't unreasonable. >> The question to consider is probably whether or not the new behavior would >> be surprising to somebody who knows all the rest of the HTML semantics. >> >> >> To be honest, I find this inference quite unremarkable and easy to grok - >> perhaps this is because it's a well known 'thing' at this point that >> <head>'s constructor is HTMLHeadElement, <button>'s is HTMLButtonElement, >> and...well you get the picture. The fact is, *most *element constructor >> names magically correspond with their associated tag names - that yacht has >> sailed. >> >> >> I think that Rick point is that in all of the cases you just cited what >> is happening is that an already existing globally name constructor is being >> instantiated. A new global name binding isn't automatically created. >> >> >> "Why is there such a strong desire to create new <script> semantics?" - I >> don't see where this *is* new script semantics, to our developer-users >> anyway. Scripts won't look or feel (or smell?) any different than they do >> now. >> >> We already decided to magically infer that custom elements are denoted >> by, and require, the presence of a magical dash in the tag name - something >> rather alien to existing tags - yet I heard no one vehemently opposed *that >> *injection of new paradigm/magic...I digress. >> >> >> I wouldn't call it magic, but it did seem very strange to me when I saw >> it. But not the most important point for now. It's more of an impedance >> mismatch. We know we are dealing with two different language that have to >> integrate and one of them does not allow "-" in names. Choosing a naming >> conventions that includes "-" is guaranteed to require more complex name >> mapping rules. >> >> >> Question: would you require a constructor="" attribute? I don't see how >> you get away from that if you went this direction. It would be necessary >> for two reasons: >> >> - Without it, you would need to assume a constructor name - which is >> basically what you want to avoid. >> - There must be some constructor name or else <element> won't be able >> to sanely register the tag. >> >> (note that register method >> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#extensions-to-document-interface only >> seems to require the tag-name. The constructor (actually prototype in this >> definition) doesn't seem to need to have a bound name. ) >> >> I may disagree with Rick, in that I'm not opposed to automatically >> providing the constructor if there isn't a "constructor=" attribute. But >> it should not introduce a new globally named constructor. >> >> I see two ways you might do this: >> >> 1) create a new *anonymous* constructor object that inherits from >> HTMLElement. It wouldn't have any unique behavior but it would be uniquely >> associated the particular <element> that defined it and it might be useful >> for doing instanceof tests. It would be the constructor that you register >> with the tag. >> >> 2) Have a new kind of HTML*Element that is used when instantiating all >> custom elements that don't have explicit constructors. As a placeholder >> name I'll use HTMLAppDefinedElement. One system defined >> HTMLAppDefinedElement constructor can be used for all such custom elements >> because they have no distinguishing behavior. So every <x-foo> would have >> a dom node that was an instance of HTMLAppDefinedElement and so would every >> <x-bar>. The instances only differ in their identify and the value of the >> tag names (and their children, etc.). >> >> Note in both these cases there are no <element> specific behaviors and >> hence no need to install prototype properties. I think if an element needs >> such custom behavior it should be required to use a "constructor=" >> attribute to associate an app provided constructor object with the element >> and the constructor should be specified in a normal <script> bock using >> normal JS techniques. >> >> It would be a mistake to automatically generate the constructor and then >> to invent some new convention to be used in a special kind of nested script >> block for installing properties into a prototype of the generated >> constructor. This is one of the main things I was objecting to, JS already >> has multiple ways to define constructors and ES6 will have a very >> straightforward way using class declarations. We don't need a new ad hoc >> way for this specific use case. >> >> For what it's worth, I have nothing against making constructor="" an >> option that is used instead of the tag name, but why force extra >> boilerplate if people would be just as comfortable dealing with a >> constructor name based on the tag name they specify? (as elements do now) >> >> The purpose of "constructor=" should be to explicitly say, this <element> >> uses a app defined element constructor which is hereby identified. The >> absence should indicate that a platform provided element constructor will >> be used >> >> Allen >> >> >> >
Received on Sunday, 14 April 2013 05:09:03 UTC