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 wrote:
 Nope, you're 100% right, I saw header and thought HTMLHeadingElement 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, Feb 19, 2013 at 9:17 PM, Scott Miles sjmi...@google.com wrote:

 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 Tue, Feb 19, 2013 at 8:34 PM, Daniel Buchner dan...@mozilla.com
 wrote:

 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 sjmi...@google.com wrote:

 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
 localName to use? I believe the notion was that the localName would be
 inferred from the prototype, but there are various semantic tags that share
 prototypes, so it seems ambiguous in these cases.

 S



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'
...



On Wed, Feb 20, 2013 at 9:54 AM, Dimitri Glazkov dglaz...@google.comwrote:

 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
 wrote:
  Nope, you're 100% right, I saw header and thought HTMLHeadingElement 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, Feb 19, 2013 at 9:17 PM, Scott Miles sjmi...@google.com wrote:
 
  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 Tue, Feb 19, 2013 at 8:34 PM, Daniel Buchner dan...@mozilla.com
  wrote:
 
  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 sjmi...@google.com wrote:
 
  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
  localName to use? I believe the notion was that the localName would be
  inferred from the prototype, but there are various semantic tags that
 share
  prototypes, so it seems ambiguous in these cases.
 
  S



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 constructor. We had a rule that you get
one kind of node for 'custom' elements and another for extensions of known
elements. But now it's more complicated.

Scott

On Wed, Feb 20, 2013 at 10:39 AM, Dimitri Glazkov dglaz...@google.comwrote:

 On Wed, Feb 20, 2013 at 10:34 AM, Scott Miles sjmi...@google.com wrote:
  var FancyHeader = document.register('fancy-header', {prototype:
  FancyHeaderPrototype});
  document.appendChild(new FancyHeader());
 
  what I expect in my document:
 
  !-- better have localName 'header', because I specifically want to
  communicate that semantic --
  header is=fancy-header

 But semantic is only important in markup? If you're building this
 imperatively, there's really no semantics anymore. You're in a DOM
 tree.

 Now, a valid question would be: what if I wanted to serialize this DOM
 tree in a certain way? I don't have an answer to that.

 :DG



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 only important on some platforms. If
that's the winning argument, then isn't it pathological to make the 'non
constructor-returning API' return a constructor?


On Mon, Feb 18, 2013 at 12:59 PM, Daniel Buchner dan...@mozilla.com wrote:

 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 this function (or any function for that matter), I'd be a much happier
 camper if I didn't have to think about handling different return values. Is
 there a clear harm in returning a constructor reliably that would make us
 want to diverge from an expected and reliable return value? It seems to me
 that the unexpected return value will be far more annoying than a little
 less mental separation between the two invocation setups.

 Daniel J. Buchner
 Product Manager, Developer Ecosystem
 Mozilla Corporation


 On Mon, Feb 18, 2013 at 12:47 PM, Dimitri Glazkov dglaz...@google.comwrote:

 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
 takes
  multiple input types is not an empirical negative, you may argue it is
 an
  ugly pattern, but that is largely subjective.

 For what it's worth, I totally agree with Anne that two-prong API is a
 huge wart and I feel shame for proposing it. But I would rather feel
 shame than waiting for Godot.

 
  Is this an accurate summary of what we're looking at for possible
 solutions?
  If so, can we at least get a decision on whether or not _this_ route is
  acceptable?
 
  FOO_CONSTRUCTOR = document.register(‘x-foo’, {
prototype: ELEMENT_PROTOTYPE,
lifecycle: {
   created: CALLBACK
}
  });

 I will spec this first.

 
  FOO_CONSTRUCTOR = document.register(‘x-foo’, {
constructor: FOO_CONSTRUCTOR
  });
 

 When we have implementers who can handle it, I'll spec that.

 Eventually, we'll work to deprecate the first approach.

 One thing that Scott suggested recently is that the second API variant
 always returns undefined, to better separate the two APIs and their
 usage patterns.

 :DG





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 though, I'll certainly defer to you all on
the best course :)

Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation


On Tue, Feb 19, 2013 at 12:51 PM, Scott Miles sjmi...@google.com wrote:

  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 only important on some platforms. If
 that's the winning argument, then isn't it pathological to make the 'non
 constructor-returning API' return a constructor?


 On Mon, Feb 18, 2013 at 12:59 PM, Daniel Buchner dan...@mozilla.comwrote:

 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 this function (or any function for that matter), I'd be a much happier
 camper if I didn't have to think about handling different return values. Is
 there a clear harm in returning a constructor reliably that would make us
 want to diverge from an expected and reliable return value? It seems to me
 that the unexpected return value will be far more annoying than a little
 less mental separation between the two invocation setups.

 Daniel J. Buchner
 Product Manager, Developer Ecosystem
 Mozilla Corporation


 On Mon, Feb 18, 2013 at 12:47 PM, Dimitri Glazkov dglaz...@google.comwrote:

 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
 takes
  multiple input types is not an empirical negative, you may argue it is
 an
  ugly pattern, but that is largely subjective.

 For what it's worth, I totally agree with Anne that two-prong API is a
 huge wart and I feel shame for proposing it. But I would rather feel
 shame than waiting for Godot.

 
  Is this an accurate summary of what we're looking at for possible
 solutions?
  If so, can we at least get a decision on whether or not _this_ route is
  acceptable?
 
  FOO_CONSTRUCTOR = document.register(‘x-foo’, {
prototype: ELEMENT_PROTOTYPE,
lifecycle: {
   created: CALLBACK
}
  });

 I will spec this first.

 
  FOO_CONSTRUCTOR = document.register(‘x-foo’, {
constructor: FOO_CONSTRUCTOR
  });
 

 When we have implementers who can handle it, I'll spec that.

 Eventually, we'll work to deprecate the first approach.

 One thing that Scott suggested recently is that the second API variant
 always returns undefined, to better separate the two APIs and their
 usage patterns.

 :DG






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
localName to use? I believe the notion was that the localName would be
inferred from the prototype, but there are various semantic tags that share
prototypes, so it seems ambiguous in these cases.

S


On Tue, Feb 19, 2013 at 1:01 PM, Daniel Buchner dan...@mozilla.com wrote:

 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 though, I'll certainly defer to you all on
 the best course :)

 Daniel J. Buchner
 Product Manager, Developer Ecosystem
 Mozilla Corporation


 On Tue, Feb 19, 2013 at 12:51 PM, Scott Miles sjmi...@google.com wrote:

  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 only important on some platforms. 
 If
 that's the winning argument, then isn't it pathological to make the 'non
 constructor-returning API' return a constructor?


 On Mon, Feb 18, 2013 at 12:59 PM, Daniel Buchner dan...@mozilla.comwrote:

 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 this function (or any function for that matter), I'd be a much happier
 camper if I didn't have to think about handling different return values. Is
 there a clear harm in returning a constructor reliably that would make us
 want to diverge from an expected and reliable return value? It seems to me
 that the unexpected return value will be far more annoying than a little
 less mental separation between the two invocation setups.

 Daniel J. Buchner
 Product Manager, Developer Ecosystem
 Mozilla Corporation


 On Mon, Feb 18, 2013 at 12:47 PM, Dimitri Glazkov 
 dglaz...@google.comwrote:

 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
 takes
  multiple input types is not an empirical negative, you may argue it
 is an
  ugly pattern, but that is largely subjective.

 For what it's worth, I totally agree with Anne that two-prong API is a
 huge wart and I feel shame for proposing it. But I would rather feel
 shame than waiting for Godot.

 
  Is this an accurate summary of what we're looking at for possible
 solutions?
  If so, can we at least get a decision on whether or not _this_ route
 is
  acceptable?
 
  FOO_CONSTRUCTOR = document.register(‘x-foo’, {
prototype: ELEMENT_PROTOTYPE,
lifecycle: {
   created: CALLBACK
}
  });

 I will spec this first.

 
  FOO_CONSTRUCTOR = document.register(‘x-foo’, {
constructor: FOO_CONSTRUCTOR
  });
 

 When we have implementers who can handle it, I'll spec that.

 Eventually, we'll work to deprecate the first approach.

 One thing that Scott suggested recently is that the second API variant
 always returns undefined, to better separate the two APIs and their
 usage patterns.

 :DG







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 sjmi...@google.com wrote:

 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
 localName to use? I believe the notion was that the localName would be
 inferred from the prototype, but there are various semantic tags that share
 prototypes, so it seems ambiguous in these cases.

 S


 On Tue, Feb 19, 2013 at 1:01 PM, Daniel Buchner dan...@mozilla.comwrote:

 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 though, I'll certainly defer to you all on
 the best course :)

 Daniel J. Buchner
 Product Manager, Developer Ecosystem
 Mozilla Corporation


 On Tue, Feb 19, 2013 at 12:51 PM, Scott Miles sjmi...@google.com wrote:

  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 only important on some platforms. 
 If
 that's the winning argument, then isn't it pathological to make the 'non
 constructor-returning API' return a constructor?


 On Mon, Feb 18, 2013 at 12:59 PM, Daniel Buchner dan...@mozilla.comwrote:

 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 this function (or any function for that matter), I'd be a much happier
 camper if I didn't have to think about handling different return values. Is
 there a clear harm in returning a constructor reliably that would make us
 want to diverge from an expected and reliable return value? It seems to me
 that the unexpected return value will be far more annoying than a little
 less mental separation between the two invocation setups.

 Daniel J. Buchner
 Product Manager, Developer Ecosystem
 Mozilla Corporation


 On Mon, Feb 18, 2013 at 12:47 PM, Dimitri Glazkov 
 dglaz...@google.comwrote:

 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
 takes
  multiple input types is not an empirical negative, you may argue it
 is an
  ugly pattern, but that is largely subjective.

 For what it's worth, I totally agree with Anne that two-prong API is a
 huge wart and I feel shame for proposing it. But I would rather feel
 shame than waiting for Godot.

 
  Is this an accurate summary of what we're looking at for possible
 solutions?
  If so, can we at least get a decision on whether or not _this_ route
 is
  acceptable?
 
  FOO_CONSTRUCTOR = document.register(‘x-foo’, {
prototype: ELEMENT_PROTOTYPE,
lifecycle: {
   created: CALLBACK
}
  });

 I will spec this first.

 
  FOO_CONSTRUCTOR = document.register(‘x-foo’, {
constructor: FOO_CONSTRUCTOR
  });
 

 When we have implementers who can handle it, I'll spec that.

 Eventually, we'll work to deprecate the first approach.

 One thing that Scott suggested recently is that the second API variant
 always returns undefined, to better separate the two APIs and their
 usage patterns.

 :DG








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 Tue, Feb 19, 2013 at 8:34 PM, Daniel Buchner dan...@mozilla.com wrote:

 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 sjmi...@google.com wrote:

 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
 localName to use? I believe the notion was that the localName would be
 inferred from the prototype, but there are various semantic tags that share
 prototypes, so it seems ambiguous in these cases.

 S


 On Tue, Feb 19, 2013 at 1:01 PM, Daniel Buchner dan...@mozilla.comwrote:

 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 though, I'll certainly defer to you all on
 the best course :)

 Daniel J. Buchner
 Product Manager, Developer Ecosystem
 Mozilla Corporation


 On Tue, Feb 19, 2013 at 12:51 PM, Scott Miles sjmi...@google.comwrote:

  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 only important on some 
 platforms. If
 that's the winning argument, then isn't it pathological to make the 'non
 constructor-returning API' return a constructor?


 On Mon, Feb 18, 2013 at 12:59 PM, Daniel Buchner dan...@mozilla.comwrote:

 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 this function (or any function for that matter), I'd be a much 
 happier
 camper if I didn't have to think about handling different return values. 
 Is
 there a clear harm in returning a constructor reliably that would make us
 want to diverge from an expected and reliable return value? It seems to me
 that the unexpected return value will be far more annoying than a little
 less mental separation between the two invocation setups.

 Daniel J. Buchner
 Product Manager, Developer Ecosystem
 Mozilla Corporation


 On Mon, Feb 18, 2013 at 12:47 PM, Dimitri Glazkov dglaz...@google.com
  wrote:

 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 takes
  multiple input types is not an empirical negative, you may argue it
 is an
  ugly pattern, but that is largely subjective.

 For what it's worth, I totally agree with Anne that two-prong API is a
 huge wart and I feel shame for proposing it. But I would rather feel
 shame than waiting for Godot.

 
  Is this an accurate summary of what we're looking at for possible
 solutions?
  If so, can we at least get a decision on whether or not _this_
 route is
  acceptable?
 
  FOO_CONSTRUCTOR = document.register(‘x-foo’, {
prototype: ELEMENT_PROTOTYPE,
lifecycle: {
   created: CALLBACK
}
  });

 I will spec this first.

 
  FOO_CONSTRUCTOR = document.register(‘x-foo’, {
constructor: FOO_CONSTRUCTOR
  });
 

 When we have implementers who can handle it, I'll spec that.

 Eventually, we'll work to deprecate the first approach.

 One thing that Scott suggested recently is that the second API variant
 always returns undefined, to better separate the two APIs and their
 usage patterns.

 :DG








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, Feb 19, 2013 at 9:17 PM, Scott Miles sjmi...@google.com wrote:

 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 Tue, Feb 19, 2013 at 8:34 PM, Daniel Buchner dan...@mozilla.comwrote:

 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 sjmi...@google.com wrote:

 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
 localName to use? I believe the notion was that the localName would be
 inferred from the prototype, but there are various semantic tags that share
 prototypes, so it seems ambiguous in these cases.

 S


 On Tue, Feb 19, 2013 at 1:01 PM, Daniel Buchner dan...@mozilla.comwrote:

 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 though, I'll certainly defer to you all
 on the best course :)

 Daniel J. Buchner
 Product Manager, Developer Ecosystem
 Mozilla Corporation


 On Tue, Feb 19, 2013 at 12:51 PM, Scott Miles sjmi...@google.comwrote:

  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 only important on some
 platforms. If that's the winning argument, then isn't it pathological
 to make the 'non constructor-returning API' return a constructor?


 On Mon, Feb 18, 2013 at 12:59 PM, Daniel Buchner 
 dan...@mozilla.comwrote:

 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 this function (or any function for that matter), I'd be a much 
 happier
 camper if I didn't have to think about handling different return values. 
 Is
 there a clear harm in returning a constructor reliably that would make us
 want to diverge from an expected and reliable return value? It seems to 
 me
 that the unexpected return value will be far more annoying than a little
 less mental separation between the two invocation setups.

 Daniel J. Buchner
 Product Manager, Developer Ecosystem
 Mozilla Corporation


 On Mon, Feb 18, 2013 at 12:47 PM, Dimitri Glazkov 
 dglaz...@google.com wrote:

 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 takes
  multiple input types is not an empirical negative, you may argue
 it is an
  ugly pattern, but that is largely subjective.

 For what it's worth, I totally agree with Anne that two-prong API is
 a
 huge wart and I feel shame for proposing it. But I would rather feel
 shame than waiting for Godot.

 
  Is this an accurate summary of what we're looking at for possible
 solutions?
  If so, can we at least get a decision on whether or not _this_
 route is
  acceptable?
 
  FOO_CONSTRUCTOR = document.register(‘x-foo’, {
prototype: ELEMENT_PROTOTYPE,
lifecycle: {
   created: CALLBACK
}
  });

 I will spec this first.

 
  FOO_CONSTRUCTOR = document.register(‘x-foo’, {
constructor: FOO_CONSTRUCTOR
  });
 

 When we have implementers who can handle it, I'll spec that.

 Eventually, we'll work to deprecate the first approach.

 One thing that Scott suggested recently is that the second API
 variant
 always returns undefined, to better separate the two APIs and their
 usage patterns.

 :DG









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 takes
 multiple input types is not an empirical negative, you may argue it is an
 ugly pattern, but that is largely subjective.

For what it's worth, I totally agree with Anne that two-prong API is a
huge wart and I feel shame for proposing it. But I would rather feel
shame than waiting for Godot.


 Is this an accurate summary of what we're looking at for possible solutions?
 If so, can we at least get a decision on whether or not _this_ route is
 acceptable?

 FOO_CONSTRUCTOR = document.register(‘x-foo’, {
   prototype: ELEMENT_PROTOTYPE,
   lifecycle: {
  created: CALLBACK
   }
 });

I will spec this first.


 FOO_CONSTRUCTOR = document.register(‘x-foo’, {
   constructor: FOO_CONSTRUCTOR
 });


When we have implementers who can handle it, I'll spec that.

Eventually, we'll work to deprecate the first approach.

One thing that Scott suggested recently is that the second API variant
always returns undefined, to better separate the two APIs and their
usage patterns.

:DG



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 this function (or any function for that matter), I'd be a much happier
camper if I didn't have to think about handling different return values. Is
there a clear harm in returning a constructor reliably that would make us
want to diverge from an expected and reliable return value? It seems to me
that the unexpected return value will be far more annoying than a little
less mental separation between the two invocation setups.

Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation


On Mon, Feb 18, 2013 at 12:47 PM, Dimitri Glazkov dglaz...@google.comwrote:

 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
 takes
  multiple input types is not an empirical negative, you may argue it is an
  ugly pattern, but that is largely subjective.

 For what it's worth, I totally agree with Anne that two-prong API is a
 huge wart and I feel shame for proposing it. But I would rather feel
 shame than waiting for Godot.

 
  Is this an accurate summary of what we're looking at for possible
 solutions?
  If so, can we at least get a decision on whether or not _this_ route is
  acceptable?
 
  FOO_CONSTRUCTOR = document.register(‘x-foo’, {
prototype: ELEMENT_PROTOTYPE,
lifecycle: {
   created: CALLBACK
}
  });

 I will spec this first.

 
  FOO_CONSTRUCTOR = document.register(‘x-foo’, {
constructor: FOO_CONSTRUCTOR
  });
 

 When we have implementers who can handle it, I'll spec that.

 Eventually, we'll work to deprecate the first approach.

 One thing that Scott suggested recently is that the second API variant
 always returns undefined, to better separate the two APIs and their
 usage patterns.

 :DG



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 standardization and will come to haunt us in the
future (in terms of maintenance, QA, new extensions to the platform,
etc.).


-- 
http://annevankesteren.nl/



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
ugly pattern, but that is largely subjective.

Is this an accurate summary of what we're looking at for possible
solutions? If so, can we at least get a decision on whether or not _this_
route is acceptable?

FOO_CONSTRUCTOR = document.register(‘x-foo’, {
  prototype: ELEMENT_PROTOTYPE,
  lifecycle: {
 created: CALLBACK
  }
});

FOO_CONSTRUCTOR = document.register(‘x-foo’, {
  constructor: FOO_CONSTRUCTOR
});





Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation


On Fri, Feb 15, 2013 at 6:19 AM, Anne van Kesteren ann...@annevk.nl wrote:

 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 standardization and will come to haunt us in the
 future (in terms of maintenance, QA, new extensions to the platform,
 etc.).


 --
 http://annevankesteren.nl/



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 plumbing
 2) document.register returns a custom element constructor as a result,
 just like currently specified:

 https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#dfn-document-register
 3) There are two ways to register an element: with a constructor and
 with a prototype object.
 4) When registering with the constructor (aka the ES6 way), you must
 supply the constructor/class as the constructor member in the
 ElementRegistrationOptions dictionary
 (
 https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#api-element-registration-options
 )
 5) If the constructor is supplied, element registration overrides
 [[Construct]] internal function as described in
 http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0250.html
 6) Registering with a prototype object (aka the current way) uses the
 prototype member in ElementRegistrationOptions dictionary and works
 roughly as currently specified


See Q's below...


 7) If the prototype object is supplied, the constructor is generated
 as two steps:
   a) Instantiate the platform object
   b) Call created callback from lifecycle callback interface bound to
 this
 8) We remove any sort of shadow tree creation and the corresponding
 template argument from the spec. Shadow tree management is left
 completely up to the author.

 Effectively, the created callback becomes the poor man's
 constructor. It's very easy to convert from old syntax to new syntax:

 The prototype way:

 function MyButton() {
   // do constructor stuff ...
 }
 MyButton.prototype = Object.create(HTMLButtonElement.prototype, {
  ...
 });
 MyButton = document.register(‘x-button’, {
   prototype: MyButton.prototype,
   lifecycle: {
  created: MyButton
   }
 });



Does this actually mean that the second argument has a property called
prototype that itself has a special meaning?

Is the re-assignment MyButton intentional? I see the original MyButton
reference as the value of the created property, but then
document.register's return value is assigned to the same identifier? Maybe
this was a typo?




 The constructor way:

 function MyButton() {
  // do constructor stuff ...
 }
 MyButton.prototype = Object.create(HTMLButtonElement.prototype, {
  ...
 });
 document.register(‘x-button’, {
  constructor: MyButton,
  ...
 });


Same question as above, but re: constructor?


When I first read this, I was expecting to see something about syntax, this
is all API.


Rick




 This is nearly the same approach as what  Scott sketched out here:
 http://jsfiddle.net/aNHZH/7/, so we already know it's shimmable :)

 What do you think?

 :DG




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 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 plumbing
 2) document.register returns a custom element constructor as a result,
 just like currently specified:

 https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#dfn-document-register
 3) There are two ways to register an element: with a constructor and
 with a prototype object.
 4) When registering with the constructor (aka the ES6 way), you must
 supply the constructor/class as the constructor member in the
 ElementRegistrationOptions dictionary
 (
 https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#api-element-registration-options
 )
 5) If the constructor is supplied, element registration overrides
 [[Construct]] internal function as described in
 http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0250.html
 6) Registering with a prototype object (aka the current way) uses the
 prototype member in ElementRegistrationOptions dictionary and works
 roughly as currently specified
 7) If the prototype object is supplied, the constructor is generated
 as two steps:
   a) Instantiate the platform object
   b) Call created callback from lifecycle callback interface bound to
 this
 8) We remove any sort of shadow tree creation and the corresponding
 template argument from the spec. Shadow tree management is left
 completely up to the author.

 Effectively, the created callback becomes the poor man's
 constructor. It's very easy to convert from old syntax to new syntax:

 The prototype way:

 function MyButton() {
   // do constructor stuff ...
 }
 MyButton.prototype = Object.create(HTMLButtonElement.prototype, {
  ...
 });
 MyButton = document.register(‘x-button’, {
   prototype: MyButton.prototype,
   lifecycle: {
  created: MyButton
   }
 });

 The constructor way:

 function MyButton() {
  // do constructor stuff ...
 }
 MyButton.prototype = Object.create(HTMLButtonElement.prototype, {
  ...
 });
 document.register(‘x-button’, {
  constructor: MyButton,
  ...
 });

 This is nearly the same approach as what  Scott sketched out here:
 http://jsfiddle.net/aNHZH/7/, so we already know it's shimmable :)

 What do you think?

 :DG



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 4:48 PM, Dimitri Glazkov dglaz...@google.comwrote:


 MyButton = document.register(‘x-button’, {
   prototype: MyButton.prototype,
   lifecycle: {
  created: MyButton
   }
 });



 Does this actually mean that the second argument has a property called
 prototype that itself has a special meaning?


This is just a dictionary.



 Is the re-assignment MyButton intentional? I see the original MyButton
 reference as the value of the created property, but then
 document.register's return value is assigned to the same identifier? Maybe
 this was a typo?


 document.register(‘x-button’, {
  constructor: MyButton,
  ...
 });


 Same question as above, but re: constructor?


Same answer here.

I'm not happy with these names but I can't think of anything better.

-- 
erik


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 5:10 PM, Rick Waldron waldron.r...@gmail.comwrote:


 On Thu, Feb 14, 2013 at 4:48 PM, Dimitri Glazkov dglaz...@google.comwrote:


 MyButton = document.register(‘x-button’, {
   prototype: MyButton.prototype,
   lifecycle: {
  created: MyButton
   }
 });



 Does this actually mean that the second argument has a property called
 prototype that itself has a special meaning?


 This is just a dictionary.



 Is the re-assignment MyButton intentional? I see the original MyButton
 reference as the value of the created property, but then
 document.register's return value is assigned to the same identifier? Maybe
 this was a typo?


 document.register(‘x-button’, {
  constructor: MyButton,
  ...
 });


 Same question as above, but re: constructor?


 Same answer here.

 I'm not happy with these names but I can't think of anything better.


Fair enough, I trust your judgement here. Thanks for the follow up—always
appreciated.

Rick


 --
 erik




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 waldron.r...@gmail.comwrote:




 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 5:10 PM, Rick Waldron waldron.r...@gmail.comwrote:


 On Thu, Feb 14, 2013 at 4:48 PM, Dimitri Glazkov dglaz...@google.comwrote:


 MyButton = document.register(‘x-button’, {
   prototype: MyButton.prototype,
   lifecycle: {
  created: MyButton
   }
 });



 Does this actually mean that the second argument has a property called
 prototype that itself has a special meaning?


 This is just a dictionary.



 Is the re-assignment MyButton intentional? I see the original MyButton
 reference as the value of the created property, but then
 document.register's return value is assigned to the same identifier? Maybe
 this was a typo?


 document.register(‘x-button’, {
  constructor: MyButton,
  ...
 });


 Same question as above, but re: constructor?


 Same answer here.

 I'm not happy with these names but I can't think of anything better.


 Fair enough, I trust your judgement here. Thanks for the follow up—always
 appreciated.

 Rick


 --
 erik





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
provide an optional route that has no legacy issues for people who want to
use it?

I believe even Scott's polyfill doesn't do anything to enable
HTMLButtonElement.call(this);

Hopefully I'm in the ballpark here, but if what I said is wrong or not an
issue, what *is* the reasoning behind it?

Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation


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 the other way.


 On Thu, Feb 14, 2013 at 2:21 PM, Rick Waldron waldron.r...@gmail.comwrote:




 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 5:10 PM, Rick Waldron waldron.r...@gmail.comwrote:


 On Thu, Feb 14, 2013 at 4:48 PM, Dimitri Glazkov 
 dglaz...@google.comwrote:


 MyButton = document.register(‘x-button’, {
   prototype: MyButton.prototype,
   lifecycle: {
  created: MyButton
   }
 });



 Does this actually mean that the second argument has a property called
 prototype that itself has a special meaning?


 This is just a dictionary.



 Is the re-assignment MyButton intentional? I see the original
 MyButton reference as the value of the created property, but then
 document.register's return value is assigned to the same identifier? Maybe
 this was a typo?


 document.register(‘x-button’, {
  constructor: MyButton,
  ...
 });


 Same question as above, but re: constructor?


 Same answer here.

 I'm not happy with these names but I can't think of anything better.


 Fair enough, I trust your judgement here. Thanks for the follow up—always
 appreciated.

 Rick


 --
 erik






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 is an issue.


Or if you want you can polyfill HTMLButtonElement.call.

HTMLButtonElement.call = function() {};

On Thu, Feb 14, 2013 at 2:36 PM, Daniel Buchner dan...@mozilla.com wrote:

 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 provide an optional route that has no legacy issues for
 people who want to use it?

 I believe even Scott's polyfill doesn't do anything to enable
 HTMLButtonElement.call(this);

 Hopefully I'm in the ballpark here, but if what I said is wrong or not an
 issue, what *is* the reasoning behind it?

 Daniel J. Buchner
 Product Manager, Developer Ecosystem
 Mozilla Corporation


 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 the other way.


 On Thu, Feb 14, 2013 at 2:21 PM, Rick Waldron waldron.r...@gmail.comwrote:




 On Thu, Feb 14, 2013 at 5:15 PM, Erik Arvidsson a...@chromium.orgwrote:

 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 4:48 PM, Dimitri Glazkov dglaz...@google.com
  wrote:


 MyButton = document.register(‘x-button’, {
   prototype: MyButton.prototype,
   lifecycle: {
  created: MyButton
   }
 });



 Does this actually mean that the second argument has a property
 called prototype that itself has a special meaning?


 This is just a dictionary.



 Is the re-assignment MyButton intentional? I see the original
 MyButton reference as the value of the created property, but then
 document.register's return value is assigned to the same identifier? 
 Maybe
 this was a typo?


 document.register(‘x-button’, {
  constructor: MyButton,
  ...
 });


 Same question as above, but re: constructor?


 Same answer here.

 I'm not happy with these names but I can't think of anything better.


 Fair enough, I trust your judgement here. Thanks for the follow
 up—always appreciated.

 Rick


 --
 erik








-- 
erik


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 pointed out that since the invention of [[Create]]
override, we don't really need them anyway -- they never do anything
useful for existing HTML elements.

For your custom elements, I can totally see your library/framework
having a convention of calling the super constructor.

I did confuse matters but not putting in the invocation of the
HTMLButtonElement.call.

:DG



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 Thu, Feb 14, 2013 at 2:45 PM, Dimitri Glazkov dglaz...@google.comwrote:

 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 pointed out that since the invention of [[Create]]
 override, we don't really need them anyway -- they never do anything
 useful for existing HTML elements.

 For your custom elements, I can totally see your library/framework
 having a convention of calling the super constructor.

 I did confuse matters but not putting in the invocation of the
 HTMLButtonElement.call.

 :DG



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 the other way.

Daniel answered the direct question, I think, but let me see if I
understand the question hiding behind your question :)

Why can't we just have one API, since these two are so close already?
In other words, can we not just use constructor API and return a
generated constructor?

Do I get a cookie? :)

:DG



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 benefit of allowing this syntax? I don't immediately see why
 you
  couldn't just do it the other way.

 Daniel answered the direct question, I think,


I must have missed that.


 but let me see if I
 understand the question hiding behind your question :)

 Why can't we just have one API, since these two are so close already?
 In other words, can we not just use constructor API and return a
 generated constructor?

 Do I get a cookie? :)

 :DG


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).


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 seems to me that...

document.register('x-super-button', {
constructor: SuperButton,
lifecycle: { ... }
});

...would still be the most concise, ergonomic syntax. Truth is, devs like
property bags. Major JS frameworks commonly use the property object pattern
for the description of new components and modules. Additionally, retaining
the property bag provides freedom to add other registration-centric
options/features at a later date - unlike 20/20 localName check hindsight,
we can *start* by retaining this flexibility now, so that hindsight does
not become not 20/13 ;)

Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation


On Thu, Feb 14, 2013 at 2:41 PM, Erik Arvidsson a...@chromium.org wrote:


 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 is an issue.


 Or if you want you can polyfill HTMLButtonElement.call.

 HTMLButtonElement.call = function() {};

 On Thu, Feb 14, 2013 at 2:36 PM, Daniel Buchner dan...@mozilla.comwrote:

 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 provide an optional route that has no legacy issues for
 people who want to use it?

 I believe even Scott's polyfill doesn't do anything to enable
 HTMLButtonElement.call(this);

 Hopefully I'm in the ballpark here, but if what I said is wrong or not
 an issue, what *is* the reasoning behind it?

 Daniel J. Buchner
 Product Manager, Developer Ecosystem
 Mozilla Corporation


 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 the other way.


 On Thu, Feb 14, 2013 at 2:21 PM, Rick Waldron 
 waldron.r...@gmail.comwrote:




 On Thu, Feb 14, 2013 at 5:15 PM, Erik Arvidsson a...@chromium.orgwrote:

 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.com
  wrote:


 On Thu, Feb 14, 2013 at 4:48 PM, Dimitri Glazkov 
 dglaz...@google.com wrote:


 MyButton = document.register(‘x-button’, {
   prototype: MyButton.prototype,
   lifecycle: {
  created: MyButton
   }
 });



 Does this actually mean that the second argument has a property
 called prototype that itself has a special meaning?


 This is just a dictionary.



 Is the re-assignment MyButton intentional? I see the original
 MyButton reference as the value of the created property, but then
 document.register's return value is assigned to the same identifier? 
 Maybe
 this was a typo?


 document.register(‘x-button’, {
  constructor: MyButton,
  ...
 });


 Same question as above, but re: constructor?


 Same answer here.

 I'm not happy with these names but I can't think of anything better.


 Fair enough, I trust your judgement here. Thanks for the follow
 up—always appreciated.

 Rick


 --
 erik








 --
 erik





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 of two steps:

1) Instantiate a platform object (that's where the C++ object's
constructor is called)
2) Create a corresponding JS object (that's where the JS object's
constructor is called)

Most of the time, these happen one right after another, except when
the renderer is parsing HTML. The parser can't stop and let user code
run at any given time (again, a design limitation we have to live with
for a while). So we have to split these steps to happen at different
times:

a) The C++ step happens as the parser builds the tree
2) The JS step happens as a microtask after tree's been built.

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.

This is sad, because the next questions you'll ask will be:

Dimitri, but what if we built DOM in JS? How would this work then?
Wouldn't platform object be just a JS object? Why the heck would we
need this two-step split?

I don't have good answers. One of them is that we teach developers to
always put dummy HTMLButtonElement.call(this) lines into their element
constructors and future-proof the world like that.

:DG



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 *extends*?

In my mind, you gain widespread adoption of this if the legacy case is
super streamlined - if you tell developers:

Because we forced a constructor pattern, albeit without truly being able
to use class and extends, we hunted and pecked around the DOM and monkey
patched a bunch of things so you can construct one-off, weak sauce variants
of inherited constructors...just to use with this one method...oh, and
don't try to really use ES6 stuff, because we're just faking a small part
of it.

That sounds kinda gross IMO.

Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation


On Thu, Feb 14, 2013 at 2:53 PM, Scott Miles sjmi...@google.com wrote:




 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 benefit of allowing this syntax? I don't immediately see why
 you
  couldn't just do it the other way.

 Daniel answered the direct question, I think,


 I must have missed that.


 but let me see if I
 understand the question hiding behind your question :)

 Why can't we just have one API, since these two are so close already?
 In other words, can we not just use constructor API and return a
 generated constructor?

 Do I get a cookie? :)

 :DG


 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).



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 generated constructor, and
the other just returns a constructor unmodified (well, not in a
detectable way). My thinking was that if we have both be one and the
same API, we would have:

1) problems writing specification in an interoperable way (if you can
override [[Construct]] function, then do this...)

2) problems with authors seeing different effects of the API on each
browser (in Webcko, I get the same object as I passed in, maybe I
don't need the return value, oh wait, why does it fail in Gekit?)

Am I worrying about this too much?

:DG



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 different method.

Yes, it's not ideal, but then there is only one way to write it.


On Thu, Feb 14, 2013 at 3:16 PM, Dimitri Glazkov dglaz...@google.comwrote:

 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 generated constructor, and
 the other just returns a constructor unmodified (well, not in a
 detectable way). My thinking was that if we have both be one and the
 same API, we would have:

 1) problems writing specification in an interoperable way (if you can
 override [[Construct]] function, then do this...)

 2) problems with authors seeing different effects of the API on each
 browser (in Webcko, I get the same object as I passed in, maybe I
 don't need the return value, oh wait, why does it fail in Gekit?)

 Am I worrying about this too much?

 :DG



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 all cost, the web needs this *now*.

Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation


On Thu, Feb 14, 2013 at 3:16 PM, Dimitri Glazkov dglaz...@google.comwrote:

 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 generated constructor, and
 the other just returns a constructor unmodified (well, not in a
 detectable way). My thinking was that if we have both be one and the
 same API, we would have:

 1) problems writing specification in an interoperable way (if you can
 override [[Construct]] function, then do this...)

 2) problems with authors seeing different effects of the API on each
 browser (in Webcko, I get the same object as I passed in, maybe I
 don't need the return value, oh wait, why does it fail in Gekit?)

 Am I worrying about this too much?

 :DG



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 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 all cost, the web needs this *now*.

 Daniel J. Buchner
 Product Manager, Developer Ecosystem
 Mozilla Corporation


 On Thu, Feb 14, 2013 at 3:16 PM, Dimitri Glazkov dglaz...@google.comwrote:

 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 generated constructor, and
 the other just returns a constructor unmodified (well, not in a
 detectable way). My thinking was that if we have both be one and the
 same API, we would have:

 1) problems writing specification in an interoperable way (if you can
 override [[Construct]] function, then do this...)

 2) problems with authors seeing different effects of the API on each
 browser (in Webcko, I get the same object as I passed in, maybe I
 don't need the return value, oh wait, why does it fail in Gekit?)

 Am I worrying about this too much?

 :DG





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 clear.

-Boris



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 wanted a single API, call the property descriptor (or
something else that's general) and have it take both by checking what kind
of object the value is... ***ducks***
On Feb 14, 2013 5:14 PM, Boris Zbarsky bzbar...@mit.edu wrote:

 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
 clear.

 -Boris