Re: [webcomponents] Making the shadow root an Element

[Jonas Sicking]

On Mon, Feb 11, 2013 at 3:49 PM, Tab Atkins Jr.  wrote:
> Right now, the shadow root inside a component isn't an element, so it
> can't host styles, etc.  This makes a few things weird, though.
>
> For example, it means that it's non-trivial to get at the style of
> text nodes directly inside the shadow.  Normally you can just look at
> the parentNode of a text node, but here you have to actually look at
> the host element.  And if the host element has blocked inheritance,
> you can't even do that - you have to calculate the initial value for
> yourself, because there's nothing you can actually *ask* for the style
> information.
>
> For another example, it means that you can't do any
> inheritance-blocking yourself, without inserting an additional
> wrapper.  If you let author inheritance through, but you want to block
> specific properties, you'd want to set "property-in-question:
> default;" at the "root" of the shadow, so it'll reset to its normal
> value.  Alternately, if we implement inheritance-blocking with CSS's
> new 'all' property
> , we need to set
> it on some "root", but that doesn't yet exist.
>
> I propose that we reify the shadow root into an element, but default
> it to "display: contents;"
>  in the UA
> stylesheet. That way it has no layout effect by default, but provides
> a handy element for doing all the things I've talked about in this
> email.
>
> I haven't thought through all the implications so far, though, like
> what the element name is, if it can have attributes set on it, etc.
>
> Thoughts?

I chatted with Blake about this today and had some thoughts.

There is definitely no simple answer here, feels like using either an
Element or a DocumentFragment has some crappy behavior. So it's a
matter of choosing the less crappy option.

Pros of using a DocumentFragment:
* Neatly solves the problem of what to do if someone attempts to
insert the shadow root as a child somewhere. If the root is an Element
we have to choose between the Element suddenly no longer being a
shadow root, or throwing.
* Avoids the problem of what to do if someone sets a style attribute
on the shadow root, or otherwise attempts to style it. Currently the
shadow root doesn't appear in the flattened tree (though we could
maybe change that) which means that it can't be styled. This is
intuitive if the shadow root is a DocumentFragment but not so much if
it is an Element.

Pros of using an Element:
* Does mean that a lot of code which is used to dealing with just
Elements and Text nodes will "just work". For example jQuery code
freaked out [1] over hitting a node that wasn't an Element but still
had an innerHTML property. There will likely be other code that does
the same.
* Means that you can set attributes on the shadow root. Again, this is
likely something libraries will do as they walk around in subtrees.
Especially if they weren't written with the existence of shadow trees
in mind (i.e. all the time).
* More consistent with the current types of Nodes that exist.
Currently people expect all Text, Comment and DocumentFragments to
have the same API, while Elements have different APIs depending on
their name. (Documents are somewhere in between as we try to move them
to the first category, PIs and DocTypes can be ignored for most
intents). Adding API to *some* DocumentFragment will likely mean that
people will need to check just what type of DocumentFragment they
have. Again, see [1] for an example, there will be more as time
passes.

[1] http://bugs.jquery.com/ticket/13342

Note that the styling issue can be resolved either way. We could make
the shadow root an Element and insert it into the flattened tree, with
the default display-box value being "children". Or we could keep the
shadow root as a DocumentFragment and add a pseduo element like
::shadow-root, which lives between an element and its shadow contents.

/ Jonas

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

[Daniel Buchner]

What does it actually profit us to singularly tie document.register to
require an ES6-esque syntax before it lands anyway? No one is saying not to
use it *when it arrives*, we're offering a way to make sure the polyfill
layer isn't needlessly bound to inconsequential externalities.

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

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

[Boris Zbarsky]

On 2/14/13 6:03 PM, Dimitri Glazkov wrote:

Since these are two separate steps, I technically don't _need_ to put
HTMLButtonElement.call(this) into my element's constructor -- it's a
sure bet it will just be a useless dummy.


For HTMLButtonElement, perhaps.  But for HTMLImageElement that's less clear.

-Boris

Re: Beacon API

[Ilya Grigorik]

A lot of the discussion so far focused on the async analytics beacon +
unload use case. However, while this is an important case to consider,
let's not constrain this proposal to "on unload" case only.

Effectively, what we want is a generic "send this request sometime later, I
don't care when", where "sometime" could be after the page has unloaded, or
even during the lifetime of the page. Why would we want such a thing?

One of the largest anti-patterns in the mobile world, when it comes to
battery performance, is the inefficiency of periodic transfers: your app
occasionaly wakes up and has to cycle to full power state to send an
intermittent ping (audience measurement, analytics, whatever). These
periodic pings can easily dominate the battery consumption over the actual
resource fetch for any page or app.

By allowing an API which says "sometime later", the browser is then able to
aggregate multiple beacon requests (from many apps, tabs, or whatever
aggregation mechanism it choose to employ), and then periodically dispatch
these requests in one shot.

Something as simple as "defer" flag on an XHR would be sufficient - no
promises as to when it'll run, no success / error callbacks, etc.

ig

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

[Scott Miles]

Is saying "just do this and it will always work" not good enough?

That part I'm not getting.


On Thu, Feb 14, 2013 at 3:30 PM, Daniel Buchner  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 wrote:
>
>> 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 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

[Daniel Buchner]

No, I believe this is *precisely *the thing to worry about - these nits and
catch-case gotchas are the sort of things developers see in an emerging
API/polyfill and say "awe, that looks like an fractured, uncertain hassle,
I'll just wait until it is native in all browsers" <-- we must avoid this
at all cost, the web needs this *now*.

Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation


On Thu, Feb 14, 2013 at 3:16 PM, Dimitri Glazkov wrote:

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

[Scott Miles]

Ok. Since you showed both returning constructors, I just assumed in both
cases the returned constructor would be different, if required by platform.

I guess my attitude is to say "always write it like this MyThing =
document.register(...), because depending on your runtime scenario it may
return a different method."

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


On Thu, Feb 14, 2013 at 3:16 PM, Dimitri Glazkov wrote:

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

[Dimitri Glazkov]

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

[Scott Miles]

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

[Daniel Buchner]

The polyfill rabbit hole of half-hearted, faux-ES6 polyfilling of
constructor inheritance seems to be far deeper than both conceptually in
code-level affect than our simple examples show. Further, what is so sexy
about forcing the pattern when we can't, hard stop, no-way, polyfill *class
*and *extends*?

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

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

That sounds kinda gross IMO.

Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation


On Thu, Feb 14, 2013 at 2:53 PM, Scott Miles  wrote:

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

[Dimitri Glazkov]

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

[Scott Miles]

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

[Daniel Buchner]

Ok, I'll take your word that we get basically 1:1 and devs won't need to
recode or do any catch-casing inside constructors or protos for non-native
document.register polyfill use.

Regardless, if we are going to keep the property bag, which provides way
more than just the prototype property, it seems to me that...

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

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

Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation


On Thu, Feb 14, 2013 at 2:41 PM, Erik Arvidsson  wrote:

>
> 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.
>>
>
> Or if you want you can polyfill HTMLButtonElement.call.
>
> HTMLButtonElement.call = function() {};
>
> On Thu, Feb 14, 2013 at 2:36 PM, Daniel Buchner 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  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 
 wrote:

>
>
>
> 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, Rick Waldron > > 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

[Dimitri Glazkov]

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

[Scott Miles]

Developer cannot call HTMLButtonElement. So whatever work it represents
that MUST be done by the browser.

Perhaps the browser doesn't call that exact function, but in any event,
neither does any user code.

Note that we are specifically taking about built ins, not custom
constructors.

S


On Thu, Feb 14, 2013 at 2:45 PM, Dimitri Glazkov wrote:

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

[Dimitri Glazkov]

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

[Erik Arvidsson]

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

Or if you want you can polyfill HTMLButtonElement.call.

HTMLButtonElement.call = function() {};

On Thu, Feb 14, 2013 at 2:36 PM, Daniel Buchner  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  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 wrote:
>>>



 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, Rick Waldron 
> wrote:
>
>>
>> On Thu, Feb 14, 2013 at 4:48 PM, Dimitri Glazkov > > 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

[Scott Miles]

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 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  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 wrote:
>>
>>>
>>>
>>>
>>> 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, Rick Waldron 
 wrote:

>
> On Thu, Feb 14, 2013 at 4:48 PM, Dimitri Glazkov 
> 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


>>>
>>
>

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

[Daniel Buchner]

It seems to me (please correct me if this is inaccurate) that you can't *
really* polyfill ES6 extension of existing element constructor inheritance,
because afaik, you cannot call the existing native constructors of elements
- it throws. So if you can only do a jankified 1/2 fill, why not just
provide an optional route that has no legacy issues for people who want to
use it?

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

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

Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation


On Thu, Feb 14, 2013 at 2:23 PM, Scott Miles  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 wrote:
>
>>
>>
>>
>> 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, Rick Waldron wrote:
>>>

 On Thu, Feb 14, 2013 at 4:48 PM, Dimitri Glazkov 
 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
>>>
>>>
>>
>

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

[Scott Miles]

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

What's the benefit of allowing this syntax? I don't immediately see why you
couldn't just do it the other way.


On Thu, Feb 14, 2013 at 2:21 PM, Rick Waldron wrote:

>
>
>
> 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, Rick Waldron wrote:
>>
>>>
>>> On Thu, Feb 14, 2013 at 4:48 PM, Dimitri Glazkov 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
>>
>>
>

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

[Rick Waldron]

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, Rick Waldron wrote:
>
>>
>> On Thu, Feb 14, 2013 at 4:48 PM, Dimitri Glazkov 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
>
>

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

[Erik Arvidsson]

Yeah, this post does not really talk about syntax. It comes after a
discussion how we could use ES6 class syntax.

The ES6 classes have the same semantics as provided in this thread using
ES5.

On Thu, Feb 14, 2013 at 5:10 PM, Rick Waldron wrote:

>
> On Thu, Feb 14, 2013 at 4:48 PM, Dimitri Glazkov 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.

-- 
erik

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

[Daniel Buchner]

I love it, gives the developer control over the addition of sugar (just a
spoonful of...) and code preference, while at the same time addressing our
requirement set. Ship it!

Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation


On Thu, Feb 14, 2013 at 1:48 PM, Dimitri Glazkov 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) 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

[Rick Waldron]

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

Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

[Dimitri Glazkov]

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<

FYI: Possible RFC 6455 (WebSocket) throttling erratum

[Bjoern Hoehrmann]

Hi,

  http://www.ietf.org/mail-archive/web/hybi/current/msg09970.html is re
http://www.ietf.org/mail-archive/web/hybi/current/msg09961.html about an
ambiguity in RFC 6455 regarding how implementations are to limit con-
current WebSocket connections. A particular point that has been raised
is http://www.ietf.org/mail-archive/web/hybi/current/msg09971.html that
the requirement should perhaps apply only to "web browsers", which would
mean the WebSocket API specification might be a better place for the re-
quirement.

regards,
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

[admin] Editors: check the URL scheme of your stylesheets

[Arthur Barstow]

Editors - below is some additional information about a side-effect of 
the recent hg administration change, the essence summarized by Robin in:


[[


dvcs.w3 [now] enforces HTTPS. If you're pointing to non-HTTP resources, 
some browsers will refuse to load them.

]]

If your hg-based specs/EDs refer to a stylesheet, the scheme must be 
https; otherwise, the document doesn't display properly on some browsers 
(as described below). Please check your specs/EDs and change them 
accordingly.


EDs that appear to have this problem (based on using Chrome 24.0...): 
DOM4, IDB, Progress Events, Quota Management, URL, Web App Manifest, Web 
Intents, XHR.


-Thanks, AB



 Original Message 
Subject: 	Fwd: [Bug 20945] New: Specs in dvcs have mixed-content 
stylesheets

Resent-Date:Mon, 11 Feb 2013 12:13:58 +
Resent-From:
Date:   Mon, 11 Feb 2013 13:13:42 +0100
From:   ext Robin Berjon 
To: WebApps WG 



Hi WebApps,

this was directed to completely the wrong Bugzilla, but I believe that
it is nevertheless true of several of your specs that are on dvcs.w3.

I would recommend someone went through them all to figure out which ones
are broken by this.

 Original Message 
From: bugzi...@jessica.w3.org
To: ro...@w3.org
Subject: [Bug 20945] New: Specs in dvcs have mixed-content stylesheets
Date: Mon, 11 Feb 2013 07:01:07 +

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20945

Bug ID: 20945
   Summary: Specs in dvcs have mixed-content stylesheets
Classification: Unclassified
   Product: HTML WG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Editor tools
  Assignee: ro...@w3.org
  Reporter: jruder...@gmail.com
QA Contact: public-html-bugzi...@w3.org
CC: eocon...@apple.com, erika.do...@microsoft.com,
silviapfeiff...@gmail.com, tra...@microsoft.com

e.g. https://dvcs.w3.org/hg/undomanager/raw-file/default/undomanager.html

The document is served over https but uses a stylesheet served
over http.  This does not work in Chrome and will soon stop working in
Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=834836).

--
You are receiving this mail because:
You are the assignee for the bug.

--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: Beacon API

[Anne van Kesteren]

On Thu, Feb 14, 2013 at 12:38 PM, Reitbauer, Alois
 wrote:
> What exactly do you mean by failed. Was nobody interested in it?

There was some misguided controversy about the feature and I think
that pretty much did it in. It has all the same characteristics as
this new proposal, but maybe this one will not get the misguided
controversy?

(The controversy was that ping was designed for tracking. That it
would improve the situation for the end user over invisible tracking
(as this could be disabled) was not taken into account obviously.)


-- 
http://annevankesteren.nl/

Re: Beacon API

[Reitbauer, Alois]

What exactly do you mean by failed. Was nobody interested in it?

On 2/14/13 1:34 PM, "Anne van Kesteren"  wrote:

>On Thu, Feb 14, 2013 at 12:28 PM, Reitbauer, Alois
> wrote:
>> I do not see how this relates to the ping. If I understand the Ping
>> correctly it send back the ping when a ling was clicked. The scenario
>>here
>> is totally different. An analytics tool - whether RUM or other
>>analytics -
>> collects a set of data like timing values etc. and then wants to beacon
>> this data back to the server for further processing. I am not sure how
>>to
>> achieve this using the ping attribute.
>
>Sure, you can achieve even more with an API as you propose, but the
>idea is the same. The user navigates and the user agent is responsible
>to do some phone-home thingie. My point is that ping="" failed thus
>far, even though it's simpler conceptually.
>
>
>--
>http://annevankesteren.nl/
>

The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Compuware Austria GmbH (registration number FN 91482h) is a 
company registered in Vienna whose registered office is at 1120 Wien, Austria, 
Am Euro Platz 2 / Gebäude G.

Re: Beacon API

[Anne van Kesteren]

On Thu, Feb 14, 2013 at 12:28 PM, Reitbauer, Alois
 wrote:
> I do not see how this relates to the ping. If I understand the Ping
> correctly it send back the ping when a ling was clicked. The scenario here
> is totally different. An analytics tool - whether RUM or other analytics -
> collects a set of data like timing values etc. and then wants to beacon
> this data back to the server for further processing. I am not sure how to
> achieve this using the ping attribute.

Sure, you can achieve even more with an API as you propose, but the
idea is the same. The user navigates and the user agent is responsible
to do some phone-home thingie. My point is that ping="" failed thus
far, even though it's simpler conceptually.


-- 
http://annevankesteren.nl/

Re: Beacon API

[Reitbauer, Alois]

In the cases I see we are never interested in the response. The question
would also be how to handle it as the page that initiated it might - or
will - no longer be there.

I do not see how this relates to the ping. If I understand the Ping
correctly it send back the ping when a ling was clicked. The scenario here
is totally different. An analytics tool - whether RUM or other analytics -
collects a set of data like timing values etc. and then wants to beacon
this data back to the server for further processing. I am not sure how to
achieve this using the ping attribute.

This could be achieved by a method like this:

beacon (method, URL, postBody);

Today people are also using img tags that are dynamically created to
achieve this. This has the downside that a) it does not always work and b)
is limited in the amount of data that can be sent back due to URL length
restrictions.

// Alois

On 2/14/13 11:04 AM, "Anne van Kesteren"  wrote:

>On Thu, Feb 14, 2013 at 9:55 AM, Reitbauer, Alois
> wrote:
>> You are right we would not need any progress events and you are also
>> typically not interested in the response. The server should normally
>>reply
>> only with a no content reply. Conceptually this reply would not be
>>needed,
>> however, HTTP requires it. You can think of this type of interaction
>>like
>> sending an UDP packet. You want it to be send and delivered at best
>> effort.
>
>Are you sometimes interested in the response? Kind of makes a difference.
>
>Also, how is this different from
>http://www.whatwg.org/specs/web-apps/current-work/#ping Especially if
>we make this a dedicated feature in some way it seems all the same
>considerations apply and that feature has thus far not been hugely
>successful.
>
>
>--
>http://annevankesteren.nl/
>

The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Compuware Austria GmbH (registration number FN 91482h) is a 
company registered in Vienna whose registered office is at 1120 Wien, Austria, 
Am Euro Platz 2 / Gebäude G.

Re: Beacon API

[Reitbauer, Alois]

I think CORS might still be needed as the data is not necessarily posted to the 
origin server. The name unloadRequest might be a bit misleading as this 
functionality might be used in a non unload situation as well. I also agree on 
the script-only capability.

// Alois

From: Dave Methvin mailto:dave.meth...@gmail.com>>
Date: Wednesday, February 13, 2013 7:18 PM
To: "Tab Atkins Jr." mailto:jackalm...@gmail.com>>
Cc: Jatinder Mann mailto:jm...@microsoft.com>>, 
"ann...@opera.com" 
mailto:ann...@opera.com>>, 
"public-webapps@w3.org" 
mailto:public-webapps@w3.org>>, Alois Reitbauer 
mailto:alois.reitba...@compuware.com>>
Subject: Re: Beacon API

On Wed, Feb 13, 2013 at 11:45 AM, Tab Atkins Jr.
I started a thread last year in WHATWG about this subject, though from
a slightly different angle:
.

A new simple API sounds like the best solution. Adding a sufficiently limited 
beacon into XHR would seem to involve a lot of special cases, since you don't 
want the response, callbacks, CORS, etc. but the requests themselves would need 
to stay around after the page is done.

It might be handy to have a method property to specify get/post and I'd prefer 
a name like unloadRequest since it's making a request and not setting a 
handler. Finally, is script-only capability sufficient or does it make sense to 
also have some form of markup specifying a link to be visited when the page 
unloads? 


The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Compuware Austria GmbH (registration number FN 91482h) is a 
company registered in Vienna whose registered office is at 1120 Wien, Austria, 
Am Euro Platz 2 / Geb?ude G.

Re: Beacon API

[Anne van Kesteren]

On Thu, Feb 14, 2013 at 9:55 AM, Reitbauer, Alois
 wrote:
> You are right we would not need any progress events and you are also
> typically not interested in the response. The server should normally reply
> only with a no content reply. Conceptually this reply would not be needed,
> however, HTTP requires it. You can think of this type of interaction like
> sending an UDP packet. You want it to be send and delivered at best
> effort.

Are you sometimes interested in the response? Kind of makes a difference.

Also, how is this different from
http://www.whatwg.org/specs/web-apps/current-work/#ping Especially if
we make this a dedicated feature in some way it seems all the same
considerations apply and that feature has thus far not been hugely
successful.


-- 
http://annevankesteren.nl/

Re: Beacon API

[Reitbauer, Alois]

Anne,

Some more details that should help to clarify:

You are right we would not need any progress events and you are also
typically not interested in the response. The server should normally reply
only with a no content reply. Conceptually this reply would not be needed,
however, HTTP requires it. You can think of this type of interaction like
sending an UDP packet. You want it to be send and delivered at best
effort.

// Alois

On 2/13/13 5:46 PM, "Anne van Kesteren"  wrote:

>On Wed, Feb 13, 2013 at 4:03 PM, Jatinder Mann 
>wrote:
>> How interested is this working group in taking on such work in the XHR
>>Level
>> 2 specification?
>
>There's plans to develop a better API for XMLHttpRequest, that would
>be somewhat more object-oriented, use DOMFuture, etc., but reuse the
>same underlying architecture.
>
>I have started drafting the plan to define the underlying
>architecture: http://wiki.whatwg.org/wiki/Fetch
>
>I'd prefer waiting with adding new features in networking land until
>that is sorted out, but I'm open to suggestions on how to proceed
>otherwise. Also, some more details with respect to expected
>functionality would be necessary. I assume for this object you would
>not need progress events or return values, but should the browser
>await a full HTTP response from the server anyway? Etc.
>
>Thanks!
>
>
>--
>http://annevankesteren.nl/
>

The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Compuware Austria GmbH (registration number FN 91482h) is a 
company registered in Vienna whose registered office is at 1120 Wien, Austria, 
Am Euro Platz 2 / Gebäude G.

Re: Beacon API

[Reitbauer, Alois]

Some comments on the post:

First I do not think we need special markup for this. Analytics tools will
trigger this programatically. I am however not sure whether the update
handler would really work. It does not solve the problem of the cancelled
XHR requests. It will also not be enough to just send the request when the
page is unloaded as some code might need to be executed first. In some
case a single XHR request is also not enough. We have rare situations when
we need to send more than one request.

// Alois

On 2/13/13 5:45 PM, "Tab Atkins Jr."  wrote:

>On Wed, Feb 13, 2013 at 8:03 AM, Jatinder Mann 
>wrote:
>> The Web Performance working group has been tracking a known poor
>>performance
>> pattern involving XHRs.
>>
>> We have seen cases where analytics code will block the unloading of the
>> document in order to send data. To guarantee that the data is sent to
>>their
>> servers, analytics will typically register a handler on the unload
>>event,
>> which will make a synchronous XHR call to submit the data. The
>>synchronous
>> XHR forces the browser to delay unloading the document, and makes the
>>next
>> navigation appear to be slower. There is little the next page can do to
>> avoid this perception of poor page load performance.
>>
>> Frankly, analytics don¹t have many good options. Browsers will typically
>> just ignore asynchronous XHR in an unload handler. Sending the data too
>>soon
>> may mean that they miss out on some data gathering opportunities. To
>>solve
>> this problem, the Web Performance WG has included writing a Beacon API
>>in
>> its charter [1]. This API would be an interoperable means for site
>> developers to asynchronously transfer data from the user agent to a web
>> server, with a guarantee from the user agent that the data will be
>> eventually sent.
>>
>> However, instead of inventing a new way to send data, it may make sense
>>to
>> first explore whether we can update XHR to help in this scenario. This
>> change could be as simple as adding an optional parameter to XHR, a new
>>type
>> of XHR (e.g., BeaconXHLHttpRequest), or just normative text on the
>>expected
>> user agent behavior when a synchronous XHR call is made in the unload
>>event
>> handler.
>>
>> How interested is this working group in taking on such work in the XHR
>>Level
>> 2 [2] specification?
>
>I started a thread last year in WHATWG about this subject, though from
>a slightly different angle:
>
>.
> The analytics use-case is a good one.
>
>~TJ
>

The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Compuware Austria GmbH (registration number FN 91482h) is a 
company registered in Vienna whose registered office is at 1120 Wien, Austria, 
Am Euro Platz 2 / Gebäude G.