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
34 matches
Mail list logo
