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

>> 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 04:14:13 UTC