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
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'
[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
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
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
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
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
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
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,
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
On Mon, Feb 11, 2013 at 8:40 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/7/13 6:15 PM, Dimitri Glazkov wrote:
1) Expose the ability to override [[Construct]]. Arv tells me that he
spoke with V8 peeps and they think they can do this fairly easily. How's
the SpiderMonkey story looking here?
On 2/7/13 6:15 PM, Dimitri Glazkov wrote:
1) Expose the ability to override [[Construct]]. Arv tells me that he
spoke with V8 peeps and they think they can do this fairly easily. How's
the SpiderMonkey story looking here?
Requires major surgery on how functions are implemented; not likely in
On Thu, Feb 7, 2013 at 11:51 PM, Scott Miles sjmi...@google.com wrote:
P.P.S. Arv, do you have a preference from my three versions (or none of the
above)?
I prefer number 2. This is what we want for ES6 anyway. Both 1 and 3
makes me have to repeat myself.
--
erik
The idea is supposed to be that 1 and 3 are only stopgaps until we get
'what we want'. In the future when you can derive a DOM element directly,
both bits of extra code can fall away. Was that clear? Does it change
anything in your mind?
If we go with 2, I believe it means nobody will ever use a
On Fri, Feb 8, 2013 at 11:54 AM, Scott Miles sjmi...@google.com wrote:
The idea is supposed to be that 1 and 3 are only stopgaps until we get 'what
we want'. In the future when you can derive a DOM element directly, both
bits of extra code can fall away. Was that clear? Does it change anything
Sorry, I'm not quite following.
1. We cannot really extends anything else but
HTMLElement/HTMLUnknownElement.
2. We cannot return the correct function object from document.register.
I don't see why these are true?
(Btw note that my 'solution 3' removes the 'return a function from
register' and
On 2/8/13 5:11 PM, Erik Arvidsson wrote:
1. We cannot really extends anything else but HTMLElement/HTMLUnknownElement.
Note that this restriction is not limited to polyfills. Extending other
HTMLElements with a custom tagname seems ... highly undesirable to me.
In particular, if you have an
On Fri, Feb 8, 2013 at 12:18 PM, Scott Miles sjmi...@google.com wrote:
Sorry, I'm not quite following.
1. We cannot really extends anything else but
HTMLElement/HTMLUnknownElement.
2. We cannot return the correct function object from document.register.
I don't see why these are true?
1.
1. Because an element with tagName === 'my-button' will not be
an HTMLButtonElement instance.
Yes, but as I mentioned, the latest notion I undersstood was that we would
support button is='my-button' syntax in this case.
2. We cannot return the correct function object from document.register.
On Fri, Feb 8, 2013 at 3:13 PM, Scott Miles sjmi...@google.com wrote:
Aha, I see, that's a very good question.
Being discussed here.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20913
:DG
I think we have the solution for polyfills: return a slightly different
object from document.register. Should we do the same thing for ES5/3 or
should we spec this as overwriting of the [[Construct]] method?
:DG
On Wed, Feb 6, 2013 at 10:01 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/6/13 5:07 PM, Erik Arvidsson wrote:
This refactoring is needed for ES6 anyway so it might be worth looking
into no matter what.
Well, yes, but it's a matter of timeframes. It's incredibly unlikely that
a complete
In my excitement for getting something that worked on the Big Three
(webkit, IE, FF), I inadvertently cheated by adding an extra parameter to
'document.register'.
TL;DR version:
Solutions to the extra parameter problem:
1. go ahead and have an (optional) extra parameter to document.register
Good reminder. On webkit/ff at least, we have made polyfills which can
generate:
x-element // for elements derived from HTMLUnknownElement
button is=x-element // for all other elements
Since both syntaxes are now (to be) supported by spec, I think we are ok?
Scott
P.S. 100% of the custom
Scott is right, there isn't a great polyfill answer for this part of the
spec, but fortunately it doesn't affect too potential many use-cases.
Developers will still go bananas for the functionality we can provide in
legacy UA versions.
- Daniel
On Feb 7, 2013 8:51 PM, Scott Miles
On 2/5/13 10:28 PM, Boris Zbarsky wrote:
And the point is that document.register changes the [[Construct]] of
MyButton but does nothing else with it?
Note that I'm still checking how feasible this is in SpiderMonkey on any
sort of finite timeframe, if we do decide to do this. Functions right
Le 06/02/2013 11:27, Boris Zbarsky a écrit :
On 2/5/13 10:28 PM, Boris Zbarsky wrote:
And the point is that document.register changes the [[Construct]] of
MyButton but does nothing else with it?
Note that I'm still checking how feasible this is in SpiderMonkey on
any sort of finite
On 2/6/13 10:36 AM, David Bruant wrote:
As a band-aid short-term type of solution, the exposed function could be
a proxy to the actual function with a specific construct trap
There is no exposed function. In Erik's proposal the function is
provided by the script and then the script keeps
On 2/6/13 10:46 AM, Boris Zbarsky wrote:
There is no exposed function. In Erik's proposal the function is
provided by the script and then the script keeps using it; the caller is
expected to mutate the [[Construct]]
I meant the _callee_ of course. ;)
-Boris
On Tue, Feb 5, 2013 at 8:26 PM, Daniel Buchner dan...@mozilla.com wrote:
I have two questions:
Does this affect our ability to polyfill doc.register in current browsers?
Good point. This is really important to us as well so we most likely
need to tweak this to make sure it will work.
Do we
On Wed, Feb 6, 2013 at 5:27 AM, Boris Zbarsky bzbar...@mit.edu wrote:
Note that I'm still checking how feasible this is in SpiderMonkey on any
sort of finite timeframe, if we do decide to do this. Functions right now
don't have a [[Construct]] member in spidermonkey that's stored on a
On Wed, Feb 6, 2013 at 12:47 PM, Scott Miles sjmi...@google.com wrote:
Instead of passing in functions to document.register we can call methods
on the custom element.
My understanding is that the 'passing in functions' was a design decision,
not a technical one. IOW, Dimitri spec'd it that
On 2/6/13 5:07 PM, Erik Arvidsson wrote:
This refactoring is needed for ES6 anyway so it might be worth looking
into no matter what.
Well, yes, but it's a matter of timeframes. It's incredibly unlikely
that a complete refactoring of how functions are implemented (which is
what I was given
On Wed, Feb 6, 2013 at 9:03 AM, Erik Arvidsson a...@chromium.org wrote:
On Tue, Feb 5, 2013 at 8:26 PM, Daniel Buchner dan...@mozilla.com wrote:
I have two questions:
Does this affect our ability to polyfill doc.register in current
browsers?
Good point. This is really important to us as
On Wed, Feb 6, 2013 at 9:56 AM, Erik Arvidsson a...@chromium.org wrote:
On Wed, Feb 6, 2013 at 12:47 PM, Scott Miles sjmi...@google.com wrote:
Instead of passing in functions to document.register we can call
methods
on the custom element.
My understanding is that the 'passing in
On Tue, Feb 5, 2013 at 5:43 PM, Daniel Buchner dan...@mozilla.com wrote:
So we're removing the async nature of the API? How is this a good trade? I
thought this was one of the benefits? Is polyfilling still possible in a
sane way that adheres to the specified behavior?
I don't think anyone
On Wed, Feb 6, 2013 at 9:03 AM, Erik Arvidsson a...@chromium.org wrote:
Do we need to be able to do new MyButton or is
document.createElement/innerHTML/parser sufficient? If we need to be
able to do new in the polyfill I think we either need to tweak
document.register or get the developer to
So, neglecting issues around the syntax of document.register and the
privatization of callbacks, is it fair to say the following is the intended
future:
class MyButton extends HTMLButtonElement {
constructor() {
super();
// make root, etc.
}
}
document.register('x-button', MyButton);
Instead of passing in functions to document.register we can call methods
on the custom element.
My understanding is that the 'passing in functions' was a design decision,
not a technical one. IOW, Dimitri spec'd it that way so these (private)
lifecycle methods aren't just sitting there on the
To be clear, the actual current spec is only:
var MyButton = document.register('my-button', {
prototype: aPROTOTYPE
});
So, while Arv has included non-spec 'created' and 'attributeChanged', you
have completely omitted 'prototype'.
Also, wrt call methods on the custom element, I believe all
Sorry, replace MyButton.super() with MyButton.super.call(this);
On Wed, Feb 6, 2013 at 10:37 AM, Scott Miles sjmi...@google.com wrote:
So, neglecting issues around the syntax of document.register and the
privatization of callbacks, is it fair to say the following is the intended
future:
On Wed, Feb 6, 2013 at 1:38 PM, Scott Miles sjmi...@google.com wrote:
Sorry, replace MyButton.super() with MyButton.super.call(this);
On Wed, Feb 6, 2013 at 10:37 AM, Scott Miles sjmi...@google.com wrote:
So, neglecting issues around the syntax of document.register and the
privatization of
On Wed, Feb 6, 2013 at 11:18 AM, Erik Arvidsson a...@chromium.org wrote:
On Wed, Feb 6, 2013 at 1:38 PM, Scott Miles sjmi...@google.com wrote:
Sorry, replace MyButton.super() with MyButton.super.call(this);
On Wed, Feb 6, 2013 at 10:37 AM, Scott Miles sjmi...@google.com wrote:
So,
Errata:
makePrototypeTwiddlingConstructorForDomNodes needs to know the extendee
var ctor = makePrototypeTwiddlingConstructorForDomNodes(inExtends, inClass);
On Wed, Feb 6, 2013 at 11:59 AM, Scott Miles sjmi...@google.com wrote:
On Wed, Feb 6, 2013 at 11:18 AM, Erik Arvidsson
There were several errors in my pseudo-code, here is a working version:
http://jsfiddle.net/yNbnL/1/
S
On Wed, Feb 6, 2013 at 12:01 PM, Scott Miles sjmi...@google.com wrote:
Errata:
makePrototypeTwiddlingConstructorForDomNodes needs to know the extendee
var ctor =
Scott: is this example not intended to work in IE9? It throws, the output
object is missing the 'oranginate' method.
Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation
On Wed, Feb 6, 2013 at 12:32 PM, Scott Miles sjmi...@google.com wrote:
There were several errors in
Yes, it's not intended to work in IE ... I used __proto__.
On Wed, Feb 6, 2013 at 12:41 PM, Daniel Buchner dan...@mozilla.com wrote:
Scott: is this example not intended to work in IE9? It throws, the output
object is missing the 'oranginate' method.
Daniel J. Buchner
Product Manager,
Sorry for the flood, but here is another version that shows inheriting from
custom elements (Webkit/FF only).
http://jsfiddle.net/cEmZq/
On Wed, Feb 6, 2013 at 12:43 PM, Scott Miles sjmi...@google.com wrote:
Yes, it's not intended to work in IE ... I used __proto__.
On Wed, Feb 6, 2013 at
Arg, I messed up the link there. Corrected: http://jsfiddle.net/cEmZq/1/
On Wed, Feb 6, 2013 at 12:47 PM, Scott Miles sjmi...@google.com wrote:
Sorry for the flood, but here is another version that shows inheriting
from custom elements (Webkit/FF only).
http://jsfiddle.net/cEmZq/
On Wed,
If we are willing to return a new constructor function I think we have
no problems. I was concerned that it would lead to people using the
wrong function but it does solve the issues.
class MyButtonImpl extends HTMLButtonElement {
}
let MyButton = document.register('my-button', {
class:
Afaik, the 'generated constructor' is technical debt we are stuck with
until we can actually invoke DOM constructors from JS. If there is a better
way around it, I'm all ears!
polyfilling without __proto__: I don't know if it's possible, which is a
good point. I was basically ignoring that
Well, this (non-robust quicky test) works in IE:
http://jsfiddle.net/zUzCx/1/
On Wed, Feb 6, 2013 at 12:59 PM, Scott Miles sjmi...@google.com wrote:
Afaik, the 'generated constructor' is technical debt we are stuck with
until we can actually invoke DOM constructors from JS. If there is a
So you're directly setting the user-added methods on matched elements in
browsers that don't support proto, but what about accessors?
If we modified the spec (as previously suggested) to take an *unbaked*
prototype object, we could polyfill all property types:
var myButton =
On Wed, Feb 6, 2013 at 1:27 PM, Daniel Buchner dan...@mozilla.com wrote:
So you're directly setting the user-added methods on matched elements in
browsers that don't support proto, but what about accessors?
I believe those can be forwarded too, I just didn't bother in my fiddle.
Equipped
On Wed, Feb 6, 2013 at 4:27 PM, Daniel Buchner dan...@mozilla.com wrote:
So you're directly setting the user-added methods on matched elements in
browsers that don't support proto, but what about accessors?
If we modified the spec (as previously suggested) to take an *unbaked*
prototype
I just made sure it worked, and it does. As for developers freaking out, I
really don't believe they would. If that was the case,
Object.defineProperties should be causing a global pandemic of
whopperdeveloper freakouts (
http://www.youtube.com/watch?v=IhF6Kr4ITNQ).
This would give us easy IE
Remember where we started: absurdly clean ES6 class syntax.
Requiring class definition class using property descriptors is a radical
march in the other direction.
I'm hardcore about syntactical tidiness. The reason I'm not freaking out
about defineProperties is IMO because I can avoid it when I
I guess it isn't a show stopper for poly-*ish*-fills, I would just wrap the
native document.register method where it is present sniff the incoming
prototype property value to detect whether it was baked cache the unbaked
prototype then pass a baked one to the native method.
Of course this
Seems like you decided that descriptor syntax is *necessary* for IE
compatibility. I'm 80% sure it is not.
S
On Wed, Feb 6, 2013 at 2:10 PM, Daniel Buchner dan...@mozilla.com wrote:
I guess it isn't a show stopper for poly-*ish*-fills, I would just wrap
the native document.register method
Short of running Object.getOwnPropertyNames on the existing node then
iterating over each to grab the property descriptor with
Object.getOwnPropertyDescriptor to rebuild an unbaked object and finally
setting the properties with Object.setProperties, I am unaware of how to do
so - is there an
If that works, then what's the problem? It only need be done once per
component.
I'm still confused, because it seems to me that 'unbaked object allowance
route' == components only work in IE if specified using tortured syntax.
That's no bueno IMO.
On Wed, Feb 6, 2013 at 2:41 PM, Daniel
The way document.register is currently proposed makes it
future-hostile to ES6. I've heard several people from different
organizations say that this is a blocking issue.
Over the last couple of days we (me, Dimitri and others) have worked
on some alterations to the current spec proposal. The
On 2/5/13 10:12 PM, Erik Arvidsson wrote:
In ES6 speak, we have split the new Foo(...args) expression into
Foo.call(Foo[@@create](), ...args) which means that creating the
instance has been separated from the call to the function.
So in particular this allows creation of uninitialized
On Tue, Feb 5, 2013 at 5:28 PM, Boris Zbarsky bzbar...@mit.edu wrote:
So in particular this allows creation of uninitialized instances in some
sense, yes?
Depends how much logic is put in the constructor vs @@create. For DOM
Elements I think we want to put *all* the logic in create. @@create
On 2/5/13 11:01 PM, Erik Arvidsson wrote:
On Tue, Feb 5, 2013 at 5:28 PM, Boris Zbarsky bzbar...@mit.edu wrote:
So in particular this allows creation of uninitialized instances in some
sense, yes?
Depends how much logic is put in the constructor vs @@create. For DOM
Elements I think we want
On Tue, Feb 5, 2013 at 3:25 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/5/13 11:01 PM, Erik Arvidsson wrote:
On Tue, Feb 5, 2013 at 5:28 PM, Boris Zbarsky bzbar...@mit.edu wrote:
So in particular this allows creation of uninitialized instances in
some
sense, yes?
Depends how much
I have two questions:
1. Does this affect our ability to polyfill doc.register in current
browsers?
2. Are you saying we're going to nix the ability to easily register
insertion, removal, and attribute change callbacks from the API?
I believe #2 is very important and should not be
*
So this won't work?*
var MyButton = document.register(‘x-mybutton’, {
prototype: Object.create(HTMLButtonElement.prototype, { ... })
});
class MySuperButton extends MyButton { ... };
document.register('x-superbutton', MySuperButton);
*But this will?*
function MyButton() {
92 matches
Mail list logo
