Re: Beacon API
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. 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 introduction of a new Future-based API for fetching. -- http://annevankesteren.nl/
Re: [webcomponents] Making the shadow root an Element
On Fri, Feb 15, 2013 at 7:12 AM, Jonas Sicking jo...@sicking.cc wrote: Adding API to *some* DocumentFragment will likely mean that people will need to check just what type of DocumentFragment they have. Although not exposed, because of template.contents we now effectively have a special type of DocumentFragment. Those with a host concept defined. A third option by the way is making this its own node type. That has its own issues of course, but would allow it to be more cleanly integrated with existing algorithms (one of the issues being that all those algorithms would have to be updated). -- http://annevankesteren.nl/
Re: Beacon API
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 privacy tradeoff for users of all browsers but better performance for some browsers than others, which will eventually lead to a predictable outcome... -Ian On Fri, Feb 15, 2013 at 3:06 AM, Anne van Kesteren ann...@annevk.nl wrote: 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. 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 introduction of a new Future-based API for fetching. -- http://annevankesteren.nl/
Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6
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 standardization and will come to haunt us in the future (in terms of maintenance, QA, new extensions to the platform, etc.). -- http://annevankesteren.nl/
Re: [XHR] withCredentials and HTTP authentication
On Tue, Feb 12, 2013 at 8:00 PM, Anne van Kesteren ann...@annevk.nl wrote: Hmm I see what you mean. But the user agent can provide the Authorization header too based on a previous visit. That is the meaning that is most often meant, but in the particular case of CORS the semantics are subtly different. Not sure how to clarify that exactly. Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=21013 -- http://annevankesteren.nl/
Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6
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
ugly pattern, but that is largely subjective.
Is this an accurate summary of what we're looking at for possible
solutions? If so, can we at least get a decision on whether or not _this_
route is acceptable?
FOO_CONSTRUCTOR = document.register(‘x-foo’, {
prototype: ELEMENT_PROTOTYPE,
lifecycle: {
created: CALLBACK
}
});
FOO_CONSTRUCTOR = document.register(‘x-foo’, {
constructor: FOO_CONSTRUCTOR
});
Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation
On Fri, Feb 15, 2013 at 6:19 AM, Anne van Kesteren ann...@annevk.nl wrote:
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 standardization and will come to haunt us in the
future (in terms of maintenance, QA, new extensions to the platform,
etc.).
--
http://annevankesteren.nl/
Re: Beacon API
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 introduction of a new Future-based API for fetching. To echo Ian's comment: I wouldn't consider ping a failure, and I think it can still be a success.. If nothing else, the practical problem is that its not universally supported, hence sites that must rely on it must implement the manual fallback anyway, at which point many just stick with that - outbound link tracking is an annoying problem that shouldn't exist. Also, I think while what we're discussing here is similar in principle, the use case is actually very different. With a ping, the action is initiated by the user. What we're asking for here is for out of band request semantics for actions initiated via JS. A good example is any form of passive audience measurment on a page, in a game, in an app, etc. The millions of real-time analytics beacons is just one example: these could be aggregated and handled much more efficiently, which would be a huge win on mobile. Similarly, same semantics extend to on unload cases covered earlier. Further, perhaps with a bit more thought.. it would also be possible to tackle the use case of aggregating background polling pings (this would require callback support, but can be restricted to requests which occur while the page is active only). For example: two background apps, each periodically polling for updates. Each submits a polling request with defer flag.. the two are bundled by the browser and issued back to back, waking up the radio once, as opposed to (potentially) twice. ig
RE: Beacon API
I worry that overloading the ping attribute here may cause confusion and may not be well adopted for the use case we have presented. Let me describe some potential requirements for such an interface. We want an asynchronous method of sending data. The interface shouldn't return a HTTP response, as the expectation is that the user agent would be responsible for sending this data when it could. The user agent must be able to send this data even after the page had unloaded, potentially even attempting to re-send it if the first attempt fails. The interface must support CORS, as one may want to send this data to a different origin. The interface wouldn't be limited to the unload and could be used at any time to reliably send data. What we wanted to understand was whether it makes more sense to create a XHR variant that does this or if it would just be less confusing to create a new beacon API, as Alois had suggested. Considering the requirements, especially if it is only designed to send data and not receive, it may just make more sense to create a specific beacon API here rather than creating a XHR invariant. I think Alois and I should come up with a more concrete proposal and then we can better weigh the pros and cons of the different approaches. Thanks, Jatinder -Original Message- From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren Sent: Thursday, February 14, 2013 5:54 AM To: Reitbauer, Alois Cc: 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 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
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 to use ping where it's supported and fallback where it's not, resulting in the same privacy tradeoff for users of all browsers but better performance for some browsers than others, which will eventually lead to a predictable outcome... Are there any websites that use it, at least in the browsers that support it? Relative lack of web developer adoption so far makes it seem like a bad bet to make more features that do the same thing, unless we're confident that we know what was wrong with a ping in the first place. - Maciej
Re: Beacon API
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 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 privacy tradeoff for users of all browsers but better performance for some browsers than others, which will eventually lead to a predictable outcome... Are there any websites that use it, at least in the browsers that support it? Relative lack of web developer adoption so far makes it seem like a bad bet to make more features that do the same thing, unless we're confident that we know what was wrong with a ping in the first place. 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 and WebKit-based browsers. I've found it hard to convince even knowledgable web developers to use this technique or a ping over synchronous XHR, even sites that are otherwise willing to do Safari-specific optimizations. I am not sure why sync XHR in unload is so tantalizing. Regards, Maciej
