Re: [webcomponents]: Of weird script elements and Benadryl

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 02:16:56 UTC