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

On Sat, Apr 13, 2013 at 7: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.
> 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?


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:

the basic semantics
the same, b/w optional constructor="" for specifying a constructor of
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.


Received on Sunday, 14 April 2013 00:38:18 UTC