Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-20 Thread Dimitri Glazkov
It seems that there's some additional reasoning that needs to go into whether an element could be constructed as custom tag. Like in this case, it should work both as a custom tag and as a type extension (the is attr). :DG On Tue, Feb 19, 2013 at 10:13 PM, Daniel Buchner dan...@mozilla.com

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-20 Thread Scott Miles
Since many of these cases are 'semantic' elements, whose only raison d'être (afaik) is having a particular localName, I'm not sure how we get around this without being able to specify an 'extends' option. document.register('fancy-header', { prototype: FancyHeaderPrototype, extends: 'header'

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-20 Thread Scott Miles
[I messed up and failed to reply-all a few messages back, see the quoted text to pick up context] semantic is only important in markup Hrm, ok. I'll have to think about that. At any rate, I'm concerned that developers will not be able to predict what kind of node they will get from a

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-19 Thread Scott Miles
I'd be a much happier camper if I didn't have to think about handling different return values. I agree, and If it were up to me, there would be just one API for document.register. However, the argument given for dividing the API is that it is improper to have a function return a value that is

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-19 Thread Daniel Buchner
What is the harm in returning the same constructor that is being input for this form of invocation? The output constructor is simply a pass-through of the input constructor, right? FOO_CONSTRUCTOR = document.register(‘x-foo’, { constructor: FOO_CONSTRUCTOR }); I guess this isn't a big deal

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-19 Thread Scott Miles
Question: if I do FancyHeaderPrototype = Object.create(HTMLElement.prototype); document.register('fancy-header', { prototype: FancyHeaderPrototype ... In this case, I intend to extend header. I expect my custom elements to look like header is=fancy-header, but how does the system know what

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-19 Thread Daniel Buchner
Wait a sec, perhaps I've missed something, but in your example you never extend the actual native header element, was that on purpose? I was under the impression you still needed to inherit from it in the prototype creation/registration phase, is that not true? On Feb 19, 2013 8:26 PM, Scott Miles

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-19 Thread Scott Miles
Perhaps I'm making a mistake, but there is no specific prototype for the native header element. 'header', 'footer', 'section', e.g., are all HTMLElement, so all I can do is FancyHeaderPrototype = Object.create(HTMLElement.prototype); Afaict, the 'headerness' cannot be expressed this way. On

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-19 Thread Daniel Buchner
Nope, you're 100% right, I saw *header *and thought HTML*Heading*Element for some reason - so this seems like a valid concern. What are the mitigation/solution options we can present to developers for this case? Daniel J. Buchner Product Manager, Developer Ecosystem Mozilla Corporation On Tue,

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-18 Thread Dimitri Glazkov
On Fri, Feb 15, 2013 at 8:42 AM, Daniel Buchner dan...@mozilla.com wrote: I'm not sure I buy the idea that two ways of doing the same thing does not seem like a good approach - the web platform's imperative and declarative duality is, by nature, two-way. Having two methods or an option that

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-18 Thread Daniel Buchner
I agree with your approach on staging the two specs for this, but the last part about returning a constructor in one circumstance and undefined in the other is something developers would rather not deal with (in my observation). If I'm a downstream consumer or library author who's going to wrap

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-15 Thread Anne van Kesteren
On Thu, Feb 14, 2013 at 9:48 PM, Dimitri Glazkov dglaz...@google.com wrote: What do you think? It seems like this still requires magic for document.createElement() and document.createElementNS(). Also, providing two ways of doing the same thing does not seem like a good approach to

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-15 Thread Daniel Buchner
I'm not sure I buy the idea that two ways of doing the same thing does not seem like a good approach - the web platform's imperative and declarative duality is, by nature, two-way. Having two methods or an option that takes multiple input types is not an empirical negative, you may argue it is an

Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-14 Thread Dimitri Glazkov
Folks, I propose just a bit of sugaring as a compromise, but I want to make sure this is really sugar and not acid, so please chime in. 1) We give up on unified syntax for ES5 and ES6, and instead focus on unified plumbing 2) document.register returns a custom element constructor as a result,

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-14 Thread Rick Waldron
On Thu, Feb 14, 2013 at 4:48 PM, Dimitri Glazkov dglaz...@google.comwrote: Folks, I propose just a bit of sugaring as a compromise, but I want to make sure this is really sugar and not acid, so please chime in. 1) We give up on unified syntax for ES5 and ES6, and instead focus on unified

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-14 Thread Daniel Buchner
I love it, gives the developer control over the addition of sugar (just a spoonful of...) and code preference, while at the same time addressing our requirement set. Ship it! Daniel J. Buchner Product Manager, Developer Ecosystem Mozilla Corporation On Thu, Feb 14, 2013 at 1:48 PM, Dimitri

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-14 Thread Erik Arvidsson
Yeah, this post does not really talk about syntax. It comes after a discussion how we could use ES6 class syntax. The ES6 classes have the same semantics as provided in this thread using ES5. On Thu, Feb 14, 2013 at 5:10 PM, Rick Waldron waldron.r...@gmail.comwrote: On Thu, Feb 14, 2013 at

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-14 Thread Rick Waldron
On Thu, Feb 14, 2013 at 5:15 PM, Erik Arvidsson a...@chromium.org wrote: Yeah, this post does not really talk about syntax. It comes after a discussion how we could use ES6 class syntax. The ES6 classes have the same semantics as provided in this thread using ES5. On Thu, Feb 14, 2013 at

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-14 Thread Scott Miles
MyButton = document.register(‘x-button’, { prototype: MyButton.prototype, lifecycle: { created: MyButton } }); What's the benefit of allowing this syntax? I don't immediately see why you couldn't just do it the other way. On Thu, Feb 14, 2013 at 2:21 PM, Rick Waldron

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-14 Thread Daniel Buchner
It seems to me (please correct me if this is inaccurate) that you can't * really* polyfill ES6 extension of existing element constructor inheritance, because afaik, you cannot call the existing native constructors of elements - it throws. So if you can only do a jankified 1/2 fill, why not just

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-14 Thread Erik Arvidsson
On Thu, Feb 14, 2013 at 5:40 PM, Scott Miles sjmi...@google.com wrote: In all constructions the *actual* calling of HTMLButtonElement is done by the browser. All the user has to do is *not* call it, and only call super constructors if they are custom. For that reason, I don't see why this

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-14 Thread Dimitri Glazkov
On Thu, Feb 14, 2013 at 2:40 PM, Scott Miles sjmi...@google.com wrote: In all constructions the *actual* calling of HTMLButtonElement is done by the browser. No, this is not correct. It's the exact opposite :) In this compromise proposal, the browser isn't calling any of the constructors. Arv

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-14 Thread Scott Miles
Developer cannot call HTMLButtonElement. So whatever work it represents that MUST be done by the browser. Perhaps the browser doesn't call that exact function, but in any event, neither does any user code. Note that we are specifically taking about built ins, not custom constructors. S On

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-14 Thread Dimitri Glazkov
On Thu, Feb 14, 2013 at 2:23 PM, Scott Miles sjmi...@google.com wrote: MyButton = document.register(‘x-button’, { prototype: MyButton.prototype, lifecycle: { created: MyButton } }); What's the benefit of allowing this syntax? I don't immediately see why you couldn't just do it

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-14 Thread Scott Miles
On Thu, Feb 14, 2013 at 2:48 PM, Dimitri Glazkov dglaz...@google.comwrote: On Thu, Feb 14, 2013 at 2:23 PM, Scott Miles sjmi...@google.com wrote: MyButton = document.register(‘x-button’, { prototype: MyButton.prototype, lifecycle: { created: MyButton } }); What's the

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-14 Thread Daniel Buchner
Ok, I'll take your word that we get basically 1:1 and devs won't need to recode or do any catch-casing inside constructors or protos for non-native document.register polyfill use. Regardless, if we are going to keep the property bag, which provides way more than just the prototype property, it

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-14 Thread Dimitri Glazkov
On Thu, Feb 14, 2013 at 2:47 PM, Scott Miles sjmi...@google.com wrote: Developer cannot call HTMLButtonElement. So whatever work it represents that MUST be done by the browser. Right. I think we're agreeing, but using different words. An instance of an HTMLButtonElement-derived element consists

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-14 Thread Daniel Buchner
The polyfill rabbit hole of half-hearted, faux-ES6 polyfilling of constructor inheritance seems to be far deeper than both conceptually in code-level affect than our simple examples show. Further, what is so sexy about forcing the pattern when we can't, hard stop, no-way, polyfill *class *and

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-14 Thread Dimitri Glazkov
On Thu, Feb 14, 2013 at 2:53 PM, Scott Miles sjmi...@google.com wrote: Well, yes, here ya go: (o). But I must be missing something. You wouldn't propose two APIs if they were equivalent, and I don't see how these are not (in any meaningful way). The only difference is that one spits out a

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-14 Thread Scott Miles
Ok. Since you showed both returning constructors, I just assumed in both cases the returned constructor would be different, if required by platform. I guess my attitude is to say always write it like this MyThing = document.register(...), because depending on your runtime scenario it may return a

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-14 Thread Daniel Buchner
No, I believe this is *precisely *the thing to worry about - these nits and catch-case gotchas are the sort of things developers see in an emerging API/polyfill and say awe, that looks like an fractured, uncertain hassle, I'll just wait until it is native in all browsers -- we must avoid this at

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-14 Thread Scott Miles
Is saying just do this and it will always work not good enough? That part I'm not getting. On Thu, Feb 14, 2013 at 3:30 PM, Daniel Buchner dan...@mozilla.com wrote: No, I believe this is *precisely *the thing to worry about - these nits and catch-case gotchas are the sort of things

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-14 Thread Boris Zbarsky
On 2/14/13 6:03 PM, Dimitri Glazkov wrote: Since these are two separate steps, I technically don't _need_ to put HTMLButtonElement.call(this) into my element's constructor -- it's a sure bet it will just be a useless dummy. For HTMLButtonElement, perhaps. But for HTMLImageElement that's less

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-14 Thread Daniel Buchner
What does it actually profit us to singularly tie document.register to require an ES6-esque syntax before it lands anyway? No one is saying not to use it *when it arrives*, we're offering a way to make sure the polyfill layer isn't needlessly bound to inconsequential externalities. Hell, if you