On 02/20/2013 08:24 AM, Reitbauer, Alois wrote:
My personal experience is different. We found that using img tags is not
that reliable. Especially in Firefox we recently saw some problems. Img
tags in general have the disadvantage that the amount of data that can
be set is rather limited. While
On Sat, Feb 16, 2013 at 11:36 AM, Reitbauer, Alois
alois.reitba...@compuware.com wrote:
The conversations this week were very helpful in deciding how to move
forward. I second Jatinder's idea that we come up with a specification that
describes in details what we need. We should also treat it
From my perspective the point is that we should rather have a clear(er)
definition of what we need, rather than starting to see how it fits into
existing specs. Having this initial spec it will be also easier to decide
about the actual fit into XHR or PING
// Alois
On 2/18/13 10:19 AM, Anne van
On Mon, Feb 18, 2013 at 4:10 PM, Reitbauer, Alois
alois.reitba...@compuware.com wrote:
From my perspective the point is that we should rather have a clear(er)
definition of what we need, rather than starting to see how it fits into
existing specs. Having this initial spec it will be also easier
On 16 February 2013 05:25, Maciej Stachowiak m...@apple.com wrote:
BTW as far as I know the best current nonblocking technique to phone home
on unload is to create an img in your unload handler pointing to the ping
URL, this will result in reliable delivery without blocking at least in IE
From: Jatinder Mann [jm...@microsoft.com]
Sent: Saturday, February 16, 2013 12:50 AM
To: Anne van Kesteren; Reitbauer, Alois
Cc: public-webapps@w3.org
Subject: RE: Beacon API
I worry that overloading the ping attribute here may cause confusion and may
not be well adopted
On Fri, Feb 15, 2013 at 12:21 AM, Ilya Grigorik igrigo...@google.com wrote:
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.
Just to be clear.
Anne,
Both Chrome and Safari support the ping attribute. I am not sure about IE,
I believe Firefox has it disabled by default. FWIW I wouldn't consider this
a huge failure, if anything I'd expect over time people to use ping where
it's supported and fallback where it's not, resulting in the same
On Fri, Feb 15, 2013 at 3:06 AM, Anne van Kesteren ann...@annevk.nl wrote:
Just to be clear. I understand why we'd want this. I'm a) wondering
why it'll be successful this time given it has the same
characteristics as ping= b) asking about the desired timeframe given
the highly likely
: Jatinder Mann; public-webapps@w3.org
Subject: Re: Beacon API
On Thu, Feb 14, 2013 at 12:38 PM, Reitbauer, Alois
alois.reitba...@compuware.com 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
On Feb 15, 2013, at 3:51 AM, Ian Fette (イアンフェッティ) ife...@google.com wrote:
Anne,
Both Chrome and Safari support the ping attribute. I am not sure about IE, I
believe Firefox has it disabled by default. FWIW I wouldn't consider this a
huge failure, if anything I'd expect over time people
On Feb 15, 2013, at 9:21 PM, Maciej Stachowiak m...@apple.com wrote:
On Feb 15, 2013, at 3:51 AM, Ian Fette (イアンフェッティ) ife...@google.com wrote:
Anne,
Both Chrome and Safari support the ping attribute. I am not sure about IE, I
believe Firefox has it disabled by default. FWIW I
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
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
On Thu, Feb 14, 2013 at 9:55 AM, Reitbauer, Alois
alois.reitba...@compuware.com 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
...@opera.com,
public-webapps@w3.orgmailto:public-webapps@w3.org
public-webapps@w3.orgmailto:public-webapps@w3.org, Alois Reitbauer
alois.reitba...@compuware.commailto: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 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.
On Thu, Feb 14, 2013 at 12:28 PM, Reitbauer, Alois
alois.reitba...@compuware.com 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
What exactly do you mean by failed. Was nobody interested in it?
On 2/14/13 1:34 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Feb 14, 2013 at 12:28 PM, Reitbauer, Alois
alois.reitba...@compuware.com wrote:
I do not see how this relates to the ping. If I understand the Ping
correctly
On Thu, Feb 14, 2013 at 12:38 PM, Reitbauer, Alois
alois.reitba...@compuware.com 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
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
I'd personally be in favour of an optional parameter that would ask the
browser to keep on with the request even after the page has been unloaded
(which would be the only solution not to block unloading while ensuring
data is delivered even for asynchronous requests).
I'm not sure how feasibly
On Wed, Feb 13, 2013 at 8:03 AM, Jatinder Mann jm...@microsoft.com 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
On Wed, Feb 13, 2013 at 4:03 PM, Jatinder Mann jm...@microsoft.com 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
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:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/035686.html
.
A new simple API sounds like the best solution. Adding a
25 matches
Mail list logo
