On Dec 7, 2013, at 3:25 PM, Dominic Cooney <domin...@google.com> wrote:
> On Sat, Dec 7, 2013 at 10:06 AM, Ryosuke Niwa <rn...@apple.com> wrote:
> On Dec 6, 2013, at 5:01 PM, Ryosuke Niwa <rn...@apple.com> wrote:
>> On Dec 6, 2013, at 1:20 AM, Brian Di Palma <off...@gmail.com> wrote:
>>> On Fri, Dec 6, 2013 at 3:24 AM, Ryosuke Niwa <rn...@apple.com> wrote:
>>>> On Nov 12, 2013, at 12:45 AM, Ryosuke Niwa <rn...@apple.com> wrote:
>>>>
>>>> On Nov 12, 2013, at 8:12 AM, Dimitri Glazkov <dglaz...@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?
>
> I'll also point out that with our proposal to add an optional template
> argument, we could do:
>
> <template id=myButton>
> ...
> </template>
> <script>
> (function () {
> class MyButton extends HTMLElement {
> ...
> }
> document.register('my-button', MyButton,
> document.getElementById('myButton'));
> )();
> </script>
>
> so authors DO have an option to hide the class entirely from the global
> scope. It's just not declarative.
>
> I don't think this proposal is an improvement over the document.register in
> the spec today.
It is an improvement in that it reduces the boilerplate code that we expect
many custom elements to have.
> The existing spec for document.register does not add a binding to the
> JavaScript scope. So it does not suffer the problem discussed in this thread.
Sorry, I don't really understand what you mean by this. Could you clarify?
> Given that we don't want to change "this" or the global object per previous
> discussion in the working group,
>
> I don't know what discussion you are specifically referring to so my next
> statement is not agreeing or disagreeing with the preceding clause of this
> sentence.
See Erik's inline comment in
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0122.html
"Unfortunately NodeJS broke this invariant already. `this` inside a module that
has been required is a not the [[Global]] object. This has caused me a lot of
personal porting pain so I agree we must not break this invariant on the web."
> I don't see how we can refer to a JS class/constructor declaratively.
>
> Yes. I can't think of an example where DOM attributes do this. onclick, etc.
> handlers relate to script, but they do not refer to specific objects.
>
> This is a problem with your proposal.
I don't think this is an issue with our proposal. I don't think any proposal
for declarative syntax can simultaneously satisfy requirements to not change
the meaning of "this" inside the element definition and not pollute the global
namespace at all.
> I think a proposal for declarative Custom Elements must also deal with the
> problems the group discovered when it last tried. They are summarized here:
> <http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0287.html>
A lot of problems listed there appears to stem from an implicit assumption that
the declarative syntax should have the same expressiveness as imperative API.
I disagree with that proposition. Any moderately complicated Web apps will
inevitably involve scripts. The existing Web APIs are designed around this
principle; they address common use cases with declarative syntax and provide
imperative APIs for more complicated use cases.
- R. Niwa
