- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 2 Dec 2013 19:56:05 -0800
- To: Ilya Grigorik <igrigorik@google.com>
- Cc: Jatinder Mann <jmann@microsoft.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
On Mon, Nov 25, 2013 at 10:43 AM, Ilya Grigorik <igrigorik@google.com> wrote:
> Assuming we drop all of the above restrictions, then the only new feature
> here is that the request can be "detached" from the parent page - i.e. if
> the page then transitions to onunload / tab is closed, then the request does
> not hold up the event and is not cancelled. With that in mind, this is more
> simply expressed as:
>
> var xhr = new XMLHttpRequest();
> xhr.detach = true; // or some such...
> ...
> xhr.open('GET', '/path');
I always felt that the main argument for not using the XHR syntax is
that the XHR syntax sucks. And most of it is there in order to provide
progress and result notifications, which I think we should avoid.
> In theory, this could provide following semantics:
> - marking request as "detach" forces it to be async (i.e. can't do sync XHR
> with detach=true)
> - detach is functionally equivalent to XHR, callbacks and all.
I explicitly do not want to provide any callbacks. That will limit the
UAs ability to be smart about when the beacon is sent. I.e. the more
information about when a beacon is sent that we expose, the larger the
risk that pages will break as implementations change when the beacon
is sent in order to save battery.
/ Jonas
Received on Tuesday, 3 December 2013 03:57:03 UTC