Re: Beacon API

2013-02-14 Thread 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

Re: Beacon API

2013-02-14 Thread 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

Re: Beacon API

2013-02-14 Thread Anne van Kesteren
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

Re: Beacon API

2013-02-14 Thread 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

Re: Beacon API

2013-02-14 Thread 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.

Re: Beacon API

2013-02-14 Thread Anne van Kesteren
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

Re: Beacon API

2013-02-14 Thread Reitbauer, Alois
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

Re: Beacon API

2013-02-14 Thread Anne van Kesteren
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

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

2013-02-14 Thread Arthur Barstow
Editors - below is some additional information about a side-effect of the recent hg administration change, the essence summarized by Robin in: [[ http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0150.html dvcs.w3 [now] enforces HTTPS. If you're pointing to non-HTTP resources,

FYI: Possible RFC 6455 (WebSocket) throttling erratum

2013-02-14 Thread 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

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

2013-02-14 Thread 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,

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

2013-02-14 Thread Rick Waldron
On Thu, Feb 14, 2013 at 4:48 PM, Dimitri Glazkov dglaz...@google.comwrote: 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

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

2013-02-14 Thread 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

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

2013-02-14 Thread 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 waldron.r...@gmail.comwrote: On Thu, Feb 14, 2013 at

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

2013-02-14 Thread Rick Waldron
On Thu, Feb 14, 2013 at 5:15 PM, Erik Arvidsson a...@chromium.org 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

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

2013-02-14 Thread 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

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

2013-02-14 Thread 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

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

2013-02-14 Thread Erik Arvidsson
On Thu, Feb 14, 2013 at 5:40 PM, Scott Miles sjmi...@google.com 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

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

2013-02-14 Thread Dimitri Glazkov
On Thu, Feb 14, 2013 at 2:40 PM, Scott Miles sjmi...@google.com 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

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

2013-02-14 Thread 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

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

2013-02-14 Thread Dimitri Glazkov
On Thu, Feb 14, 2013 at 2:23 PM, Scott Miles sjmi...@google.com 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

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

2013-02-14 Thread Scott Miles
On Thu, Feb 14, 2013 at 2:48 PM, Dimitri Glazkov dglaz...@google.comwrote: On Thu, Feb 14, 2013 at 2:23 PM, Scott Miles sjmi...@google.com wrote: MyButton = document.register(‘x-button’, { prototype: MyButton.prototype, lifecycle: { created: MyButton } }); What's the

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

2013-02-14 Thread 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

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

2013-02-14 Thread Dimitri Glazkov
On Thu, Feb 14, 2013 at 2:47 PM, Scott Miles sjmi...@google.com 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

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

2013-02-14 Thread 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

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

2013-02-14 Thread Dimitri Glazkov
On Thu, Feb 14, 2013 at 2:53 PM, Scott Miles sjmi...@google.com 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

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

2013-02-14 Thread 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

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

2013-02-14 Thread 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

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

2013-02-14 Thread 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 dan...@mozilla.com wrote: No, I believe this is *precisely *the thing to worry about - these nits and catch-case gotchas are the sort of things

Re: Beacon API

2013-02-14 Thread 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

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

2013-02-14 Thread 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

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

2013-02-14 Thread 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

Re: [webcomponents] Making the shadow root an Element

2013-02-14 Thread Jonas Sicking
On Mon, Feb 11, 2013 at 3:49 PM, Tab Atkins Jr. jackalm...@gmail.com 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