- From: Rick Waldron <waldron.rick@gmail.com>
- Date: Sat, 13 Apr 2013 20:37:31 -0400
- To: Daniel Buchner <daniel@mozilla.com>
- Cc: John J Barton <johnjbarton@johnjbarton.com>, Dimitri Glazkov <dglazkov@google.com>, Allen Wirfs-Brock <allen@wirfs-brock.com>, Scott Miles <sjmiles@google.com>, Rafael Weinstein <rafaelw@google.com>, public-webapps <public-webapps@w3.org>, Blake Kaplan <mrbkap@mozilla.com>, William Chen <wchen@mozilla.com>, Jonas Sicking <jonas@sicking.cc>, Steve Orvell <sorvell@google.com>, Dave Herman <dherman@mozilla.com>, Boris Zbarsky <bzbarsky@mit.edu>
- Message-ID: <CAHfnhfopcU4QA_bBhtE_-5tuPGhDWeqTV9jqYEvn+To+fftLrA@mail.gmail.com>
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:38:18 UTC