[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 construc
On Wed, Feb 20, 2013 at 9:58 AM, Scott Miles wrote:
> 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
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'
..
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 wrote:
> Nope, you're
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,
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
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
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 , but how does the system know what
localName to use? I beli
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 thou
>> 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
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 thi
On Fri, Feb 15, 2013 at 8:42 AM, Daniel Buchner 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
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
On Thu, Feb 14, 2013 at 9:48 PM, Dimitri Glazkov 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
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 wa
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 c
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 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 eme
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
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
On Thu, Feb 14, 2013 at 2:53 PM, Scott Miles 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 construct
Ok. Yes, I think we are actually agreeing (even though you said I had it
backwards, lol).
All I meant to say was that the fact that we can't call HTMLButtonElement
is not a practical problem because we have no need to call it.
On Thu, Feb 14, 2013 at 3:03 PM, Dimitri Glazkov wrote:
> On Thu, Fe
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 *exte
On Thu, Feb 14, 2013 at 2:47 PM, Scott Miles 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
On Thu, Feb 14, 2013 at 2:48 PM, Dimitri Glazkov wrote:
> On Thu, Feb 14, 2013 at 2:23 PM, Scott Miles wrote:
> > MyButton = document.register(‘x-button’, {
> > prototype: MyButton.prototype,
> > lifecycle: {
> > created: MyButton
> > }
> > });
> >
> > What's the benefit of allowing th
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 see
On Thu, Feb 14, 2013 at 2:23 PM, Scott Miles 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
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,
On Thu, Feb 14, 2013 at 2:40 PM, Scott Miles 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
On Thu, Feb 14, 2013 at 5:40 PM, Scott Miles 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.
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.
On Thu, Feb 14, 2013 at 2:36 PM, Daniel Buchner wrote:
> It s
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
pro
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 wrote:
>
>
>
> O
On Thu, Feb 14, 2013 at 5:15 PM, Erik Arvidsson 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, Ric
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 wrote:
>
> On Thu, Feb 14, 2013 at 4:48 PM, Dimitri Glazko
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 Glazk
On Thu, Feb 14, 2013 at 4:48 PM, Dimitri Glazkov wrote:
> 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)
36 matches
Mail list logo
