- From: Daniel Buchner <daniel@mozilla.com>
- Date: Sat, 13 Apr 2013 17:56:08 -0700
- To: Rick Waldron <waldron.rick@gmail.com>
- Cc: William Chen <wchen@mozilla.com>, Rafael Weinstein <rafaelw@google.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>, Scott Miles <sjmiles@google.com>, Dimitri Glazkov <dglazkov@google.com>
- Message-ID: <CAHZ6zJF0R7=mNnorrDr16AZJOYvhTVJXR9_vK5otTGQuCSs2PA@mail.gmail.com>
@Rick - if we generated a constructor that was in scope when the script was executed, there is no need for rebinding 'this'. I'd gladly ditch the rebinding in favor of sane, default, generated constructors. On Apr 13, 2013 5:37 PM, "Rick Waldron" <waldron.rick@gmail.com> wrote: > > > > On Sat, Apr 13, 2013 at 7:52 PM, Daniel Buchner <daniel@mozilla.com>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. >> >> 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. >> > > _NOTHING_ about those is "magic" in the context of a browser's <script> > execution and lifespan of the [[Global]] object. Those may be "generated" > by the backing implementation, but they already exist as properties of the > global object at the moment the first <script> is seen and any JS begins > executing. That is absolutely not the same thing as making a magically > generated constructor function or prototype object at some later time, > where that time _might_ be just before some <script> nested in an <element>. > > > >> The fact is, *most *element constructor names magically correspond with >> their associated tag names - that yacht has sailed. >> > > This is completely irrelevant to the creation of a _custom_ element that > _user_ _code_ defines. Besides, those objects are all provided by the > platform and it doesn't matter how they come to life, it only matters that > they already exist at the moment of first execution. > > > >> "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. >> > > So, you're telling me that you believe magical "this" binding in <script> > code isn't new semantics? > > >> 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. >> > > It's not new, look at the algorithm for creating element.dataset object > properties from dashed data-* attributes (elem.dataset.fooBar from > data-foo-bar) or CSSStyleDeclaration property names from CSS rule > declarations "marginTop is margin-top" > > >> Question: would you require a constructor="" attribute? >> > > No. > > I don't see how you get away from that if you went this direction. >> > > What direction are you talking about? > > >> 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. >> >> No, not at all... did you even read the semantics that described? I > actually _explicitly_ described how this would work. > > >> >> - There must be some constructor name or else <element> won't be able >> to sanely register the tag. >> >> Of course, see last comment. > > >> 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) >> > > I literally described this exact thing and exactly how it could work > without any new <script> semantics or any tightly coupled or nested > <script> dependency, over the course of two messages: > > 1. http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0155.html... the basic semantics > 2. > http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0178.html... the same, b/w optional constructor="" for specifying a constructor of a > completely unmatchable name. > > > The difference between what I've proposed and the snippets you've posted, > is that I've explicitly described the steps involved in making the > convention-based constructor naming "magic" work and you have not. If you > want us to use our imaginations then say so or else be explicit. > > > Rick > > >
Received on Sunday, 14 April 2013 00:56:37 UTC