Re: Beacon API
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. jackalm...@gmail.com wrote: 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 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: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/035686.html . 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.
Re: Beacon API
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 ann...@annevk.nl wrote: 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 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
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 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
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 dave.meth...@gmail.commailto:dave.meth...@gmail.com Date: Wednesday, February 13, 2013 7:18 PM To: Tab Atkins Jr. jackalm...@gmail.commailto:jackalm...@gmail.com Cc: Jatinder Mann jm...@microsoft.commailto:jm...@microsoft.com, ann...@opera.commailto:ann...@opera.com ann...@opera.commailto:ann...@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 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 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? /bikeshed 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
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 ann...@annevk.nl wrote: 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 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
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 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
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 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
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/
[admin] Editors: check the URL scheme of your stylesheets
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, 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:public-webapps@w3.org Date: Mon, 11 Feb 2013 13:13:42 +0100 From: ext Robin Berjon ro...@w3.org To: WebApps WG public-webapps@w3.org 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
FYI: Possible RFC 6455 (WebSocket) throttling erratum
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/
Custom elements ES6/ES5 syntax compromise, was: document.register and ES6
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
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 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
Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6
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 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 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
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 4:48 PM, Dimitri Glazkov dglaz...@google.comwrote:
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
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 5:10 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Thu, Feb 14, 2013 at 4:48 PM, Dimitri Glazkov dglaz...@google.comwrote:
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
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 waldron.r...@gmail.comwrote:
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 5:10 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Thu, Feb 14, 2013 at 4:48 PM, Dimitri Glazkov dglaz...@google.comwrote:
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
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 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 the other way.
On Thu, Feb 14, 2013 at 2:21 PM, Rick Waldron waldron.r...@gmail.comwrote:
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 5:10 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Thu, Feb 14, 2013 at 4:48 PM, Dimitri Glazkov
dglaz...@google.comwrote:
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
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 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 dan...@mozilla.com 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 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 the other way.
On Thu, Feb 14, 2013 at 2:21 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Thu, Feb 14, 2013 at 5:15 PM, Erik Arvidsson a...@chromium.orgwrote:
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 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
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 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
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 dglaz...@google.comwrote: 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 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
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 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
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 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
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 a...@chromium.org wrote:
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 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 dan...@mozilla.comwrote:
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 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 the other way.
On Thu, Feb 14, 2013 at 2:21 PM, Rick Waldron
waldron.r...@gmail.comwrote:
On Thu, Feb 14, 2013 at 5:15 PM, Erik Arvidsson a...@chromium.orgwrote:
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.com
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
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 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
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 sjmi...@google.com wrote:
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 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
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 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
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 dglaz...@google.comwrote: 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 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
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 dglaz...@google.comwrote: 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 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
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 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 dglaz...@google.comwrote: 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 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: Beacon API
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
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
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 bzbar...@mit.edu 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: [webcomponents] Making the shadow root an Element
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 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 http://dev.w3.org/csswg/css3-cascade/#all-shorthand, 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; http://dev.w3.org/csswg/css-display-3/#the-display-box 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
