Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6
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
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
[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
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
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
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
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
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
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
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
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
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
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/
Custom elements ES6/ES5 syntax compromise, was: document.register and ES6
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
