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

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" <> 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 <>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
>> 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