Re: [webcomponents] Binding Custom Element without Polluting Global Scope (Was Proposal for Cross Origin Use Case and Declarative Syntax)

On Sat, Dec 7, 2013 at 1:01 AM, Ryosuke Niwa <rniwa@apple.com> wrote:
> On Dec 6, 2013, at 1:20 AM, Brian Di Palma <offler@gmail.com> wrote:
>> On Fri, Dec 6, 2013 at 3:24 AM, Ryosuke Niwa <rniwa@apple.com> wrote:
>>> On Nov 12, 2013, at 12:45 AM, Ryosuke Niwa <rniwa@apple.com> wrote:
>>>
>>> On Nov 12, 2013, at 8:12 AM, Dimitri Glazkov <dglazkov@chromium.org> wrote:
>>>
>>> 1) It is not friendly to ES6 classes. In fact, you can't use class syntax
>>> and this syntax together.
>>>
>>>
>>> Okay, let the author define the constructor.
>>>
>>> 3) The approach pollutes global name space with constructors. This had been
>>> voiced many times as unacceptable by developers.
>>>
>>>
>>> We can solve this problem by using JavaScript "object path" as opposed to a
>>> variable name.
>>>
>>> So instead of:
>>> <template register="my-button" interface="MyButton">
>>> </template>
>>>
>>> We allow:
>>> <script>
>>> var my = {views:{MyButton: ~}};
>>> </script>
>>> <template register="my-button" interface="my.views.MyButton">
>>> </template>
>>>
>>> While this requires some variable to be exposed on the global scope,
>>> libraries and frameworks do this already,
>>
>> Hopefully though they won't do that any longer in the ES6 module world.
>> They had to be exposed on the global scope in some way otherwise they
>> couldn't be used, in future that will no longer be the case.
>
> Are you proposing to provide some mechanism to declaratively define a custom element inside a module?
>
> How does a ES6 module end up having markup?
>

It doesn't. I don't like mixing the different resource types inside one file.
Whether that is a HTML file with JS inside it or a JS file with HTML inside it.
I feel they should be kept separate from each other as much as possible.
Especially since I have no need for the HTML markup in my ES6 module.

The current document.register signature requires,

TYPE, the custom element type of the element being registered

PROTOTYPE, the custom element prototype, optional

So I don't see what use the HTML markup would be to me.

If we look at the proposal we are talking about here the signature has
one extra parameter added,

TEMPLATEELEMENT, HTMLTemplateElement used as template for custom element.

again I'm not sure what I'd need the HTML markup for.

You may point out that I need the HTMLTemplateElement, which is true
and for that I'd really like
to use a mechanism that as a proficient ES6+ developer I'd be quite
familiar with.

````javascript

import { myCustomElement } from "my-customelement.html";

class MyCustomElement extends HTMLElement {
        ...
}

document.register('my-customelement', MyCustomElement, myCustomElement);
````

I think in fact that the import line can be made to work with the some
tweaks to the standard module loader.
I'd much prefer this over having a HTML file containing my code and
business logic stuck inside an antiquated IIFE.

With HTTP2.0/SPDY you can have your server push the CSS files related
to the custom element so they are in cache
when the element is created if browsers don't natively support the above code.

I'd build a dependency tree by using the module loader imports so that
any dependent custom elements are available.

Actually I'm not sure I'd use HTML imports at all if I had this...I'm
sure I'm missing some benefit they would provide?

P.S.

For extra fun you could import CSS in the same way and have it apply
in scoped fashion to different elements.

````javascript

import CSSStyleSheetObject from "my-customelement.css" apply to myCustomElement;
import anotherCSSStyleSheetObject from "my-application-styles.css"
apply to document;

````

Once you have ES modules implemented this might be a quick addition
for a browser maker.

> - R. Niwa
>

Received on Saturday, 7 December 2013 12:47:02 UTC