Re: Quota API and WebApps [Was: Re: Consolidating charter changes]
Hi Arthur, On Wed, Nov 23, 2011 at 10:20 PM, Arthur Barstow art.bars...@nokia.comwrote: Hi IanF, All, Following up on Quota API vis-à-visCharterChanges wiki [1] ... Does the group want to add Quota API to the group's charter? If yes, where is a draft/strawman proposal? We have an early draft for Quota API spec here: http://wiki.whatwg.org/wiki/Quota I think we want to add it to the group's charter. -AB [1] http://www.w3.org/2008/**webapps/wiki/CharterChangeshttp://www.w3.org/2008/webapps/wiki/CharterChanges On 11/8/11 12:37 PM, ext Arthur Barstow wrote: During the October 31 meeting, we discussed [1] various additions, changes and deletions for WebApps' current charter [2]. To consolidate the various proposals, I created the following doc: http://www.w3.org/2008/**webapps/wiki/CharterChangeshttp://www.w3.org/2008/webapps/wiki/CharterChanges My expectation is that Doug will this information when he drafts our updated charter. Comments on this doc and our future charter welcome. However, if we are going to add any new deliverables, I think there should be broad agreement on the spec, including prior commitment to drive the spec through all of the phases of the process including testing and implementations. Chaals, IanF - I included some actions/questions for you (mostly recorded at the f2f meeting). -AB [1] http://www.w3.org/2011/10/31-**webapps-minutes.htmlhttp://www.w3.org/2011/10/31-webapps-minutes.html [2] http://www.w3.org/2010/**webapps/charter/http://www.w3.org/2010/webapps/charter/
Re: [XHR] responseType json
On Mon, Dec 12, 2011 at 7:08 PM, Jarred Nicholls jar...@sencha.com wrote: There's no feeding (re: streaming) of data to a parser, it's buffered until the state is DONE (readyState == 4) and then an XML doc is created upon the first access to responseXML or response. Same will go for the JSON parser in our first iteration of implementing the json responseType. FWIW, Gecko parses XML and HTML in a streaming way as data arrives from the network. When readyState changes to DONE, the document has already been parsed. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: Proposed Specification for find/findAll/matches
On 2011-12-12 17:57, Boris Zbarsky wrote: On 12/12/11 6:07 AM, Lachlan Hunt wrote: Given a selector list as input to the method, trim whitespace and then for each complex selector, run the first step that applies: (Note: if the selector list is , then there are 0 complex selectors in the list and the following doesn't run) | 1. Otherwise, if the complex selector begins with any combinator This needs to be defined better. complex selector can't begin with a combinator, per its definition. For the purposes of this API, I think the spec needs to define a modified syntax for a DOM Selector, which is similar to, but slightly different from a regular selector. The grammar production would be: dom_selectors_group : dom_selector [ COMMA S* dom_selector ]* ; dom_selector : [ combinator ]? selector ; Where the productions for combinator and selector are defined in Selectors. The spec would then define that the parameter accepts a group of DOM selectors that matches that grammar. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: HTML Speech XG Completes, seeks feedback for eventual standardization
Hi Dan, WebApps already has a relatively large number of specs in progress (see [PubStatus]) and the group has agreed to add some additional specs (see [CharterChanges]). As such, please provide a relatively specific proposal about the features/specs you and other proponents would like to add to WebApps. Regarding the level of detail for your proposal, I think a reasonable precedence is something like the Gamepad and Pointer/MouseLock proposals (see [CharterChanges]). (Perhaps this could be achieved by identifying specific sections in the XG's Final Report?) -Art Barstow [PubStatus] http://www.w3.org/2008/webapps/wiki/PubStatus#API_Specifications [CharterChanges] http://www.w3.org/2008/webapps/wiki/CharterChanges#Additions_Agreed On 12/12/11 5:25 PM, ext Dan Burnett wrote: Dear WebApps people, The HTML Speech Incubator Group [1] has recently wrapped up its work on use cases, requirements, and proposals for adding automatic speech recognition (ASR) and text-to-speech (TTS) capabilities to HTML. The work of the group is documented in the group's Final Report. [2] The members of the group intend this work to be input to one or more working groups, in W3C and/or other standards development organizations such as the IETF, as an aid to developing full standards in this space. Whether the W3C work happens in a new Working Group or an existing one, we are interested in collecting feedback on the Incubator Group's work. We are specifically interested in input from the members of the WebApps Working Group. If you have any feedback to share, please send it to, or cc, the group's mailing list (public-xg-htmlspe...@w3.org). This will allow comments to be archived in one consistent location for use by whatever group takes up this work. Dan Burnett, Co-Chair HTML Speech Incubator Group [1] charter: http://www.w3.org/2005/Incubator/htmlspeech/charter [2] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/ p.s. This feedback request is being sent to the following groups: WebApps, HTML, Audio, DAP, Voice Browser, Multimodal Interaction
Fwd: Re: Quota API and WebApps [Was: Re: Consolidating charter changes]
As IanF mentioned before, Google would like to add a Quota API to WebApps' charter and Kinuko has now provided a link to a document that provides some details about this API: http://wiki.whatwg.org/wiki/Quota As such, this is a Call for Consensus to add this API to WebApps' charter (see [CharterChanges] for latest data on WebApps' charter update). If you have any comments or concerns about this proposal, please send them to public-webapps by December 20 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. -AB [CharterChanges] http://www.w3.org/2008/webapps/wiki/CharterChanges Original Message Subject: Re: Quota API and WebApps [Was: Re: Consolidating charter changes] Date: Tue, 13 Dec 2011 17:22:38 +0900 From: ext Kinuko Yasuda kin...@chromium.org To: Arthur Barstow art.bars...@nokia.com CC: public-webapps public-webapps@w3.org, Ian Fette ife...@google.com Hi Arthur, On Wed, Nov 23, 2011 at 10:20 PM, Arthur Barstow art.bars...@nokia.com mailto:art.bars...@nokia.com wrote: Hi IanF, All, Following up on Quota API vis-à-visCharterChanges wiki [1] ... Does the group want to add Quota API to the group's charter? If yes, where is a draft/strawman proposal? We have an early draft for Quota API spec here: http://wiki.whatwg.org/wiki/Quota I think we want to add it to the group's charter. -AB [1] http://www.w3.org/2008/webapps/wiki/CharterChanges On 11/8/11 12:37 PM, ext Arthur Barstow wrote: During the October 31 meeting, we discussed [1] various additions, changes and deletions for WebApps' current charter [2]. To consolidate the various proposals, I created the following doc: http://www.w3.org/2008/webapps/wiki/CharterChanges My expectation is that Doug will this information when he drafts our updated charter. Comments on this doc and our future charter welcome. However, if we are going to add any new deliverables, I think there should be broad agreement on the spec, including prior commitment to drive the spec through all of the phases of the process including testing and implementations. Chaals, IanF - I included some actions/questions for you (mostly recorded at the f2f meeting). -AB [1] http://www.w3.org/2011/10/31-webapps-minutes.html [2] http://www.w3.org/2010/webapps/charter/
CfC: add Quota API to WebApps' charter; deadline December 20
Subject corrected ... On 12/13/11 7:22 AM, Arthur Barstow wrote: As IanF mentioned before, Google would like to add a Quota API to WebApps' charter and Kinuko has now provided a link to a document that provides some details about this API: http://wiki.whatwg.org/wiki/Quota As such, this is a Call for Consensus to add this API to WebApps' charter (see [CharterChanges] for latest data on WebApps' charter update). If you have any comments or concerns about this proposal, please send them to public-webapps by December 20 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. -AB [CharterChanges] http://www.w3.org/2008/webapps/wiki/CharterChanges Original Message Subject: Re: Quota API and WebApps [Was: Re: Consolidating charter changes] Date: Tue, 13 Dec 2011 17:22:38 +0900 From: ext Kinuko Yasuda kin...@chromium.org To: Arthur Barstow art.bars...@nokia.com CC: public-webapps public-webapps@w3.org, Ian Fette ife...@google.com Hi Arthur, On Wed, Nov 23, 2011 at 10:20 PM, Arthur Barstow art.bars...@nokia.com mailto:art.bars...@nokia.com wrote: Hi IanF, All, Following up on Quota API vis-à-visCharterChanges wiki [1] ... Does the group want to add Quota API to the group's charter? If yes, where is a draft/strawman proposal? We have an early draft for Quota API spec here: http://wiki.whatwg.org/wiki/Quota I think we want to add it to the group's charter. -AB [1] http://www.w3.org/2008/webapps/wiki/CharterChanges On 11/8/11 12:37 PM, ext Arthur Barstow wrote: During the October 31 meeting, we discussed [1] various additions, changes and deletions for WebApps' current charter [2]. To consolidate the various proposals, I created the following doc: http://www.w3.org/2008/webapps/wiki/CharterChanges My expectation is that Doug will this information when he drafts our updated charter. Comments on this doc and our future charter welcome. However, if we are going to add any new deliverables, I think there should be broad agreement on the spec, including prior commitment to drive the spec through all of the phases of the process including testing and implementations. Chaals, IanF - I included some actions/questions for you (mostly recorded at the f2f meeting). -AB [1] http://www.w3.org/2011/10/31-webapps-minutes.html [2] http://www.w3.org/2010/webapps/charter/
Re: HTML Speech XG Completes, seeks feedback for eventual standardization
Thanks for the info, Art. To be clear, I personally am *NOT* proposing adding any specs to WebApps, although others might. My email below as a Chair of the group is merely to inform people of this work and ask for feedback. I expect that your information will be useful for others who might wish for some of this work to continue in WebApps. -- dan On Dec 13, 2011, at 7:06 AM, Arthur Barstow wrote: Hi Dan, WebApps already has a relatively large number of specs in progress (see [PubStatus]) and the group has agreed to add some additional specs (see [CharterChanges]). As such, please provide a relatively specific proposal about the features/specs you and other proponents would like to add to WebApps. Regarding the level of detail for your proposal, I think a reasonable precedence is something like the Gamepad and Pointer/MouseLock proposals (see [CharterChanges]). (Perhaps this could be achieved by identifying specific sections in the XG's Final Report?) -Art Barstow [PubStatus] http://www.w3.org/2008/webapps/wiki/PubStatus#API_Specifications [CharterChanges] http://www.w3.org/2008/webapps/wiki/CharterChanges#Additions_Agreed On 12/12/11 5:25 PM, ext Dan Burnett wrote: Dear WebApps people, The HTML Speech Incubator Group [1] has recently wrapped up its work on use cases, requirements, and proposals for adding automatic speech recognition (ASR) and text-to-speech (TTS) capabilities to HTML. The work of the group is documented in the group's Final Report. [2] The members of the group intend this work to be input to one or more working groups, in W3C and/or other standards development organizations such as the IETF, as an aid to developing full standards in this space. Whether the W3C work happens in a new Working Group or an existing one, we are interested in collecting feedback on the Incubator Group's work. We are specifically interested in input from the members of the WebApps Working Group. If you have any feedback to share, please send it to, or cc, the group's mailing list (public-xg-htmlspe...@w3.org). This will allow comments to be archived in one consistent location for use by whatever group takes up this work. Dan Burnett, Co-Chair HTML Speech Incubator Group [1] charter: http://www.w3.org/2005/Incubator/htmlspeech/charter [2] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/ p.s. This feedback request is being sent to the following groups: WebApps, HTML, Audio, DAP, Voice Browser, Multimodal Interaction
[XHR]
postMessage is the new wtf
Following the recent blog post http://updates.html5rocks.com/2011/12/Transferable-Objects-Lightning-Fastand subsequent Twitter discussion regarding changes to the parameter list of: Worker.prototype.postMessage( message [, transfer ] ) [1] DedicatedWorkerGlobalScope void postMessagehttp://dev.w3.org/html5/workers/#dom-dedicatedworkerglobalscope-postmessage(any message, optional sequenceTransferable transfer) [2][3] I'm unable to find documentation or discussion that would clarify the rationale of over-using and over-loading the postMessage Identifier; considering the the blog cited above shows this example: [window|worker].webkitPostMessage(uInt8Array.buffer, [uInt8Array.buffer]); which conflicts with: window.postMessage(message, targetOrigin [, transfer ]) [4][5] and they both conflict with: DedicatedWorkerGlobalScope : WorkerGlobalScope ... void postMessage(in any message, in optional MessagePortArray ports); [6] Currently, passing a second arg to worker.postMessage(), that is not a MessagePortArray raises Uncaught TypeError: MessagePortArray argument must contain only MessagePorts in Chrome and Could not get domain warning in Firefox. Any reasonable clarification would be greatly appreciated. Thanks in advance Rick [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dedicated-workers-and-the-worker-interface [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dedicated-workers-and-the-dedicatedworkerglobalscope-interface [3] http://dev.w3.org/html5/workers/#dedicated-workers-and-the-dedicatedworkerglobalscope-interface [4] http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#web-messaging [5] http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#posting-messages [6] PREVIOUS SPECIFICATION STATE!!! http://www.w3.org/TR/2011/WD-workers-20110208/#dedicated-workers-and-the-dedicatedworkerglobalscope-interface
[widgets] How to divorce widgets-digsig from Elliptic Curve PAG?
Hi All, The Widgets DigSig spec [W-DigSig] has been sitting in PR for over 4 months now, blocked on the Elliptic Curve PAG [ECC-PAG]. AFAICT, this PAG has just started its unspecified length Fishing Expedition seeking some unspecified level of funds to pay for some type of analysis that will take some unknown amount of time to complete ... Given this, and not wanting to block on the ECC PAG any longer, what are the options to move widgets-digsig to REC ASAP? Some options: 1. Replace [XMLSig1.1] dependency with XMLSig 1.0. I presume this would require a new 3-week LC but the CR could be zero-length, presumably no re-testing would be required, and the only thing blocking PR-REC is the length of the new CfE that would be needed. 2. Move the tainted algorithm(s) in XMLSig1.1 to XMLSig1.Next so XMLSig1.1 is not affected by the PAG and XMLSig1.1 can then continue on the REC track. 3. Others? (#2 seems dead simple so I'm probably missing some things.) -AB [W-DigSig] http://www.w3.org/TR/widgets-digsig/ [XMLSig1.1] http://www.w3.org/TR/xmldsig-core1/ [ECC-PAG] http://www.w3.org/2011/02/xmlsec-pag-charter.html
[widgets] Widget Interface is a W3C Candidate Recommendation; Call for Implementations
A Candidate Recommendation of the Widget Interface spec was published today: http://www.w3.org/TR/2011/CR-widgets-apis-20111213/ If you have any implementation feedback, please send it to the public-webapps mail list.
Re: HTML Speech XG Completes, seeks feedback for eventual standardization
We at Google believe that a scripting-only (Javascript) subset of the API defined in the Speech XG Incubator Group Final Report [1] is of appropriate scope for consideration by the WebApps WG. A scripting-only subset supports the majority of the use-cases and samples in the XG proposal. Specifically, it enables web-pages to generate speech output and to use speech recognition as an input for forms, continuous dictation and control. The Javascript API will allow web pages to control activation and timing and to handle results and alternatives As Dan points out above, we envision that different portions of the Incubator Group Final Report are applicable to different working groups in W3C and/or other standards development organizations such as the IETF. This scripting API subset does not preclude other groups from pursuing standardization of relevant HTML markup or underlying transport protocols, and indeed the Incubator Group Final Report defines a potential roadmap such that such additions can be compatible. To make this more concrete, Google will provide to this mailing list a specific proposal extracted from the Incubator Group Final Report, that includes only those portions we believe are relevant to WebApps, with links back to the Incubator Report as appropriate. Bjorn Bringert Satish Sampath Glen Shires [1] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/ On Tue, Dec 13, 2011 at 5:32 AM, Dan Burnett dburn...@voxeo.com wrote: Thanks for the info, Art. To be clear, I personally am *NOT* proposing adding any specs to WebApps, although others might. My email below as a Chair of the group is merely to inform people of this work and ask for feedback. I expect that your information will be useful for others who might wish for some of this work to continue in WebApps. -- dan On Dec 13, 2011, at 7:06 AM, Arthur Barstow wrote: Hi Dan, WebApps already has a relatively large number of specs in progress (see [PubStatus]) and the group has agreed to add some additional specs (see [CharterChanges]). As such, please provide a relatively specific proposal about the features/specs you and other proponents would like to add to WebApps. Regarding the level of detail for your proposal, I think a reasonable precedence is something like the Gamepad and Pointer/MouseLock proposals (see [CharterChanges]). (Perhaps this could be achieved by identifying specific sections in the XG's Final Report?) -Art Barstow [PubStatus] http://www.w3.org/2008/webapps/wiki/PubStatus#API_Specifications [CharterChanges] http://www.w3.org/2008/webapps/wiki/CharterChanges#Additions_Agreed On 12/12/11 5:25 PM, ext Dan Burnett wrote: Dear WebApps people, The HTML Speech Incubator Group [1] has recently wrapped up its work on use cases, requirements, and proposals for adding automatic speech recognition (ASR) and text-to-speech (TTS) capabilities to HTML. The work of the group is documented in the group's Final Report. [2] The members of the group intend this work to be input to one or more working groups, in W3C and/or other standards development organizations such as the IETF, as an aid to developing full standards in this space. Whether the W3C work happens in a new Working Group or an existing one, we are interested in collecting feedback on the Incubator Group's work. We are specifically interested in input from the members of the WebApps Working Group. If you have any feedback to share, please send it to, or cc, the group's mailing list (public-xg-htmlspe...@w3.org). This will allow comments to be archived in one consistent location for use by whatever group takes up this work. Dan Burnett, Co-Chair HTML Speech Incubator Group [1] charter: http://www.w3.org/2005/Incubator/htmlspeech/charter [2] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/ p.s. This feedback request is being sent to the following groups: WebApps, HTML, Audio, DAP, Voice Browser, Multimodal Interaction
Re: postMessage is the new wtf
On Tue, Dec 13, 2011 at 2:11 PM, Dmitry Lomov dslo...@chromium.org wrote:
Hi Rick,
here are some clarifications.
There were many (long!) discussions on public-webapps about the new
signature for postMessage:
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/thread.html
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0304.html
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0805.html
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0985.html
I appreciate these links and to clarify, I wasn't subscribed to this last
in April of 2011, so my search started here:
https://www.google.com/search?gcx=csourceid=chromeie=UTF-8q=postmessage+api+change
...Among several other similar searches. I promise this wasn't a case of
just not looking, so again, thank you for providing the links
window.webkitPostMessage(msg, transferables) does not really exist (it is
an error in the blog post, and I am told the post will be amended). What
exists is window.webkitPostMessage(msg, targetOrigin, transferables).
This supports the subject line postMessage is the new wtf
Regarding second argument to worker.(webkit)postMessage, this is the new
spec for it:
http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dedicated-workers-and-the-dedicatedworkerglobalscope-interface
.
Thank you, please see [2]
The spec mandates 'void postMessage(any message, optional
sequenceTransferable transfer)'. Transferable includes both MessagePorts
and ArrayBuffers, so in the new spec the transfer argument to postMessage
may be a mix of both types, and a backwards-compat extension to what we had
before (sequenceMessagePort aka MessagePortArray). Note that message
ports got an additional change in semantics, and can now be mentioned in
the message as well - both
worker.postMessage({p:port}, [port])
and
worker.postMessage({p:port, ab:arrayBuffer}, [post, arrayBuffer])
work. Therefore this extension to postMessage semantics is both
backwards-compatible and consistent.
Can you provide a reference for this? I'm unable to locate anything that
covers these semantics.
On the receiving side, the 'ports' property of event object will still
contain only the message ports from the transfer list, so that behavior is
preserved as well.
Great!
I hope this helps,
Thanks,
Dmitry
On Tue, Dec 13, 2011 at 8:24 AM, Rick Waldron waldron.r...@gmail.comwrote:
Following the recent blog post
http://updates.html5rocks.com/2011/12/Transferable-Objects-Lightning-Fastand
subsequent Twitter discussion regarding changes to the parameter list
of:
Worker.prototype.postMessage( message [, transfer ] ) [1]
DedicatedWorkerGlobalScope void
postMessagehttp://dev.w3.org/html5/workers/#dom-dedicatedworkerglobalscope-postmessage(any
message, optional sequenceTransferable transfer) [2][3]
I'm unable to find documentation or discussion that would clarify the
rationale of over-using and over-loading the postMessage Identifier;
considering the the blog cited above shows this example:
[window|worker].webkitPostMessage(uInt8Array.buffer, [uInt8Array.buffer
]);
which conflicts with:
window.postMessage(message, targetOrigin [, transfer ]) [4][5]
and they both conflict with:
DedicatedWorkerGlobalScope : WorkerGlobalScope ...
void postMessage(in any message, in optional MessagePortArray ports); [6]
Currently, passing a second arg to worker.postMessage(), that is not a
MessagePortArray raises
Uncaught TypeError: MessagePortArray argument must contain only
MessagePorts in Chrome and Could not get domain warning in Firefox.
Any reasonable clarification would be greatly appreciated.
Thanks in advance
Rick
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dedicated-workers-and-the-worker-interface
[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dedicated-workers-and-the-dedicatedworkerglobalscope-interface
[3]
http://dev.w3.org/html5/workers/#dedicated-workers-and-the-dedicatedworkerglobalscope-interface
[4]
http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#web-messaging
[5]
http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#posting-messages
[6] PREVIOUS SPECIFICATION STATE!!!
http://www.w3.org/TR/2011/WD-workers-20110208/#dedicated-workers-and-the-dedicatedworkerglobalscope-interface
Re: postMessage is the new wtf
Hi Rick,
here are some clarifications.
There were many (long!) discussions on public-webapps about the new
signature for postMessage:
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/thread.html
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0304.html
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0805.html
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0985.html
window.webkitPostMessage(msg, transferables) does not really exist (it is
an error in the blog post, and I am told the post will be amended). What
exists is window.webkitPostMessage(msg, targetOrigin, transferables).
Regarding second argument to worker.(webkit)postMessage, this is the new
spec for it:
http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dedicated-workers-and-the-dedicatedworkerglobalscope-interface
.
The spec mandates 'void postMessage(any message, optional
sequenceTransferable transfer)'. Transferable includes both MessagePorts
and ArrayBuffers, so in the new spec the transfer argument to postMessage
may be a mix of both types, and a backwards-compat extension to what we had
before (sequenceMessagePort aka MessagePortArray). Note that message
ports got an additional change in semantics, and can now be mentioned in
the message as well - both
worker.postMessage({p:port}, [port])
and
worker.postMessage({p:port, ab:arrayBuffer}, [post, arrayBuffer])
work. Therefore this extension to postMessage semantics is both
backwards-compatible and consistent. On the receiving side, the 'ports'
property of event object will still contain only the message ports from the
transfer list, so that behavior is preserved as well.
I hope this helps,
Thanks,
Dmitry
On Tue, Dec 13, 2011 at 8:24 AM, Rick Waldron waldron.r...@gmail.comwrote:
Following the recent blog post
http://updates.html5rocks.com/2011/12/Transferable-Objects-Lightning-Fastand
subsequent Twitter discussion regarding changes to the parameter list
of:
Worker.prototype.postMessage( message [, transfer ] ) [1]
DedicatedWorkerGlobalScope void
postMessagehttp://dev.w3.org/html5/workers/#dom-dedicatedworkerglobalscope-postmessage(any
message, optional sequenceTransferable transfer) [2][3]
I'm unable to find documentation or discussion that would clarify the
rationale of over-using and over-loading the postMessage Identifier;
considering the the blog cited above shows this example:
[window|worker].webkitPostMessage(uInt8Array.buffer, [uInt8Array.buffer]);
which conflicts with:
window.postMessage(message, targetOrigin [, transfer ]) [4][5]
and they both conflict with:
DedicatedWorkerGlobalScope : WorkerGlobalScope ...
void postMessage(in any message, in optional MessagePortArray ports); [6]
Currently, passing a second arg to worker.postMessage(), that is not a
MessagePortArray raises
Uncaught TypeError: MessagePortArray argument must contain only
MessagePorts in Chrome and Could not get domain warning in Firefox.
Any reasonable clarification would be greatly appreciated.
Thanks in advance
Rick
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dedicated-workers-and-the-worker-interface
[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dedicated-workers-and-the-dedicatedworkerglobalscope-interface
[3]
http://dev.w3.org/html5/workers/#dedicated-workers-and-the-dedicatedworkerglobalscope-interface
[4]
http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#web-messaging
[5]
http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#posting-messages
[6] PREVIOUS SPECIFICATION STATE!!!
http://www.w3.org/TR/2011/WD-workers-20110208/#dedicated-workers-and-the-dedicatedworkerglobalscope-interface
Re: postMessage is the new wtf
(resending to list - Rick, sorry if you get this twice)
On Tue, Dec 13, 2011 at 11:59 AM, Rick Waldron waldron.r...@gmail.com
wrote:
On Tue, Dec 13, 2011 at 2:11 PM, Dmitry Lomov dslo...@chromium.org
wrote:
window.webkitPostMessage(msg, transferables) does not really exist (it is
an error in the blog post, and I am told the post will be amended). What
exists is window.webkitPostMessage(msg, targetOrigin, transferables).
This supports the subject line postMessage is the new wtf
You are obviously entitled to your own opinions, but folks were working
hard to make sure that changes to the spec result in API that is both makes
sense in its final form and does not break the Web.
The spec mandates 'void postMessage(any message, optional
sequenceTransferable transfer)'. Transferable includes both MessagePorts
and ArrayBuffers, so in the new spec the transfer argument to postMessage
may be a mix of both types, and a backwards-compat extension to what we had
before (sequenceMessagePort aka MessagePortArray). Note that message
ports got an additional change in semantics, and can now be mentioned in
the message as well - both
worker.postMessage({p:port}, [port])
and
worker.postMessage({p:port, ab:arrayBuffer}, [post, arrayBuffer])
work. Therefore this extension to postMessage semantics is both
backwards-compatible and consistent.
Can you provide a reference for this? I'm unable to locate anything that
covers these semantics.
A spec for structured cloning algorithm (ready-for-implementations state):
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#safe-passing-of-structured-data
A spec for typed array tarnsfer (strawman state):
http://www.khronos.org/registry/typedarray/specs/latest/#9
(I agree it is not super easy to find these, but all this is bleeding-edge
still - when dust settles, I am sure there will be more blog posts,
articles and all that jazz)
Thanks!
Dmitry
On Tue, Dec 13, 2011 at 8:24 AM, Rick Waldron waldron.r...@gmail.comwrote:
Following the recent blog post
http://updates.html5rocks.com/2011/12/Transferable-Objects-Lightning-Fastand
subsequent Twitter discussion regarding changes to the parameter list
of:
Worker.prototype.postMessage( message [, transfer ] ) [1]
DedicatedWorkerGlobalScope void
postMessagehttp://dev.w3.org/html5/workers/#dom-dedicatedworkerglobalscope-postmessage(any
message, optional sequenceTransferable transfer) [2][3]
I'm unable to find documentation or discussion that would clarify the
rationale of over-using and over-loading the postMessage Identifier;
considering the the blog cited above shows this example:
[window|worker].webkitPostMessage(uInt8Array.buffer, [uInt8Array.buffer
]);
which conflicts with:
window.postMessage(message, targetOrigin [, transfer ]) [4][5]
and they both conflict with:
DedicatedWorkerGlobalScope : WorkerGlobalScope ...
void postMessage(in any message, in optional MessagePortArray ports);
[6]
Currently, passing a second arg to worker.postMessage(), that is not a
MessagePortArray raises
Uncaught TypeError: MessagePortArray argument must contain only
MessagePorts in Chrome and Could not get domain warning in Firefox.
Any reasonable clarification would be greatly appreciated.
Thanks in advance
Rick
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dedicated-workers-and-the-worker-interface
[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dedicated-workers-and-the-dedicatedworkerglobalscope-interface
[3]
http://dev.w3.org/html5/workers/#dedicated-workers-and-the-dedicatedworkerglobalscope-interface
[4]
http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#web-messaging
[5]
http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#posting-messages
[6] PREVIOUS SPECIFICATION STATE!!!
http://www.w3.org/TR/2011/WD-workers-20110208/#dedicated-workers-and-the-dedicatedworkerglobalscope-interface
Re: postMessage is the new wtf
On Tue, Dec 13, 2011 at 11:24 AM, Rick Waldron waldron.r...@gmail.comwrote:
I'm unable to find documentation or discussion that would clarify the
rationale of over-using and over-loading the postMessage Identifier;
It's not strange that there are differences between methods on completely
different objects; it's not something that needs special explanation.
Using different names for very similar operations would be inconsistent, as
these do the same thing: post a message. The primary difference is an
added security mechanism for the cross-document messaging that
window.postMessage can perform.
Currently, passing a second arg to worker.postMessage(), that is not a
MessagePortArray raises
Uncaught TypeError: MessagePortArray argument must contain only
MessagePorts in Chrome and Could not get domain warning in Firefox.
This is a very new feature, and isn't yet available in production
browsers. Try http://tools.google.com/dlpage/chromesxs, which does have
this. (As that's a development build, it may not yet be working
completely, of course.)
On Tue, Dec 13, 2011 at 2:11 PM, Dmitry Lomov dslo...@chromium.org wrote:
window.webkitPostMessage(msg, transferables) does not really exist (it is
an error in the blog post, and I am told the post will be amended). What
exists is window.webkitPostMessage(msg, targetOrigin, transferables).
This supports the subject line postMessage is the new wtf
The subject isn't very productive approach to asking questions.
This API, and the differences between window.postMessage and
port.postMessage, is well-documented in Web Messaging.
http://dev.w3.org/html5/postmsg/#posting-messages
The spec mandates 'void postMessage(any message, optional
sequenceTransferable transfer)'. Transferable includes both MessagePorts
and ArrayBuffers, so in the new spec the transfer argument to postMessage
may be a mix of both types, and a backwards-compat extension to what we had
before (sequenceMessagePort aka MessagePortArray). Note that message
ports got an additional change in semantics, and can now be mentioned in
the message as well - both
worker.postMessage({p:port}, [port])
and
worker.postMessage({p:port, ab:arrayBuffer}, [post, arrayBuffer])
work. Therefore this extension to postMessage semantics is both
backwards-compatible and consistent.
Can you provide a reference for this? I'm unable to locate anything that
covers these semantics.
Please see the definition of postMessage, which transfers objects (search
for the text transferring the object x), and the text: To transfer a
MessagePort object old to a new owner owner, ..., which defines what
transferring does in the case of MessagePort.
--
Glenn Maynard
Re: postMessage is the new wtf
On 12/13/11 11:11 AM, Dmitry Lomov wrote:
worker.postMessage({p:port, ab:arrayBuffer}, [post, arrayBuffer])
work. Therefore this extension to postMessage semantics is both
backwards-compatible and consistent. On the receiving side, the
'ports' property of event object will still contain only the message
ports from the transfer list, so that behavior is preserved as well.
What's the behavior if an array buffer or port is not on the
transferrables list?
For example: worker.postMessage({p:port, ab:arrayBuffer})
The clone example you posted makes sense:
worker.postMessage({p:port, ab:arrayBuffer}, [post, arrayBuffer])
If transferrables is supported, it'll ensure the vars are neutered and
referenced appropriately, and if they aren't supported, it'll still pass
a copy of array buffer through the message data.
-Charles
Re: postMessage is the new wtf
Dmitry, Thanks for taking the time to provide these references and resources Rick
Re: postMessage is the new wtf
On Tue, Dec 13, 2011 at 12:30 PM, Charles Pritchard ch...@jumis.com wrote:
On 12/13/11 11:11 AM, Dmitry Lomov wrote:
worker.postMessage({p:port, ab:arrayBuffer}, [post, arrayBuffer])
work. Therefore this extension to postMessage semantics is both
backwards-compatible and consistent. On the receiving side, the 'ports'
property of event object will still contain only the message ports from the
transfer list, so that behavior is preserved as well.
What's the behavior if an array buffer or port is not on the
transferrables list?
For example: worker.postMessage({p:port, ab:arrayBuffer})
In what we ship today in WebKit, this will be an exception, because cloning
of message ports is not supported.
The clone example you posted makes sense:
worker.postMessage({p:port, ab:arrayBuffer}, [post, arrayBuffer])
If transferrables is supported, it'll ensure the vars are neutered and
referenced appropriately, and if they aren't supported, it'll still pass a
copy of array buffer through the message data.
-Charles
Re: postMessage is the new wtf
On Tue, Dec 13, 2011 at 3:30 PM, Charles Pritchard ch...@jumis.com wrote:
On 12/13/11 11:11 AM, Dmitry Lomov wrote:
worker.postMessage({p:port, ab:arrayBuffer}, [post, arrayBuffer])
work. Therefore this extension to postMessage semantics is both
backwards-compatible and consistent. On the receiving side, the 'ports'
property of event object will still contain only the message ports from the
transfer list, so that behavior is preserved as well.
What's the behavior if an array buffer or port is not on the
transferrables list?
For example: worker.postMessage({p:port, ab:arrayBuffer})
If a port is in the first argument but not listed in transfer,
DATA_CLONE_ERR will be thrown by the structured clone algorithm when it
encounters the MessagePort in step 3 of the internal structured clone
algorithm.
This doesn't happen when the port is listed for transfer, because the
MessagePort will already be in *memory* when step 1 encounters it (If
input is the source object...).
What matters to users here is that structured clone itself is always a
const operation; it never modifies its arguments. If you say
postMessage({obj: opaqueObject}), where opaqueObject is provided by a
third-party library, you never have to worry that postMessage (or
IndexedDB, or History, etc.) might modify the object and break the
library. It can only modify things that you explicitly list in transfer.
This helps future API expansion as well: transfer support can be added to
more objects in the future, without breaking existing code by causing
unexpected new side-effects.
(ArrayBuffers will simply be copied by default, since they support
structured clone.)
The clone example you posted makes sense:
worker.postMessage({p:port, ab:arrayBuffer}, [post, arrayBuffer])
If transferrables is supported, it'll ensure the vars are neutered and
referenced appropriately, and if they aren't supported, it'll still pass a
copy of array buffer through the message data.
Pre-Transferable implementations will throw here, since they only allow
MessagePort in MessagePortArray. If you want to use transfer while falling
back to copies for old browsers, you'll need to jump a few extra hoops (eg.
filter objects that aren't instances of Transferable yourself).
--
Glenn Maynard
Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?
On Tue, 2011-12-13 at 13:14 -0500, Arthur Barstow wrote: Hi All, The Widgets DigSig spec [W-DigSig] has been sitting in PR for over 4 months now, blocked on the Elliptic Curve PAG [ECC-PAG]. AFAICT, this PAG has just started its unspecified length Fishing Expedition seeking some unspecified level of funds to pay for some type of analysis that will take some unknown amount of time to complete ... Given this, and not wanting to block on the ECC PAG any longer, what are the options to move widgets-digsig to REC ASAP? Some options: 1. Replace [XMLSig1.1] dependency with XMLSig 1.0. I presume this would require a new 3-week LC but the CR could be zero-length, presumably no re-testing would be required, and the only thing blocking PR-REC is the length of the new CfE that would be needed. 2. Move the tainted algorithm(s) in XMLSig1.1 to XMLSig1.Next so XMLSig1.1 is not affected by the PAG and XMLSig1.1 can then continue on the REC track. 3. Others? An other one was for the Director to decide to move the document forward anyway because W-DigSig doesn't depend on ECC. Thomas, any suggestion? Philippe
[Bug 15094] When creating a worker, it should be possible to assign some arguments to the constructor, or pass an init object like so: var worker = new Worker(someurl.js, { someData: 1234 }); Th
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15094 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #3 from Ian 'Hixie' Hickson i...@hixie.ch 2011-12-14 00:22:12 UTC --- Doesn't seem compelling. Please don't hesitate to reopen if I've missed something obvious here. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 15141] DedicatedWorkerGlobalScope IDL formatting is broken
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15141 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||FIXED -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[stream-api] Editor's Draft for Streams API
Following the discussion we had at TPAC [1], we have uploaded our draft as an editor's draft to Mercurial: http://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm This is just a starting point for discussion and we're looking forward to incorporating feedback as we move forward. We know there are a few things that need to sync with other specs and Feras is working on that. Thanks, Adrian. [1] http://www.w3.org/2011/11/01-webapps-minutes.html#item02 On Thursday, September 22, 2011 11:35 AM, I wrote: There has been discussion in this group now and again about the need for stream support as part of the File APIs including recently in the threads about Streaming Blobs [1] and XHR streaming [2]. I've also had several private conversations with members of the WG about the need we see for this kind of stream support. Initially, we thought that supporting a streaming Blob was the correct solution but we ran into a number of issues with this as we investigated further. First of all, people were confused about using the term Blob to represent something of unknown size. Secondly, we received guidance from a number of people to keep the two concepts of Blob and Stream separate. Back in March, we provided some suggestions about using streams in the context of Media Capture and Speech with our submission to the HTML Speech XG [3]. Specifically at that time we said: We propose the addition of a stream type. While this document does not present a detailed design for this type, we assume a Stream is an object that: 1. Has a content type; 2. Has unspecified length; 3. Can generally be used in the same places Blob can be used, for example URL.createObjectURL(). Over the last six months, we have refined our thinking further and would like to submit a proposal for review by the working group that provides that detailed design. We believe that this work is part of the chartered deliverables for File API (and includes XHR support): Streams API - http://html5labs.com/streamsapi/ We recognise that there are a number of different proposals for using stream-like objects elsewhere in the web platform, usually for very specific use cases. What we have tried to define here is a Stream object that is as generic as the Blob object defined in the File API spec. As we started building applications with richer access to devices on the system including files we found the lack of support for an object representing asynchronous data of (initially) unknown size was important. Section 11 of the proposal provides examples of the scenarios we have in mind. To start to address this gap, we have implemented a preview of this mechanism in IE10 Platform Preview 3 behind a vendor prefix (e.g. MSStream) to gain more implementation experience. We look forward to hearing feedback on this proposal, which we've framed mostly as a delta against existing drafts in this working group. Thanks, Adrian. [1] http://lists.w3.org/Archives/Public/public- webapps/2011JulSep/0725.html [2] http://lists.w3.org/Archives/Public/public- webapps/2011JulSep/0741.html [3] http://lists.w3.org/Archives/Public/www-archive/2011Mar/att- 0001/microsoft-api-draft-final.html#streams
[FileAPI] Blob protocol version - is this needed?
The current spec defines the Blob Protocol Version [1]. Our current implementation doesn't require a protocol version and the way protocol handlers are defined in Internet Explorer does require this. I don't know if this is ever exposed in the web platform. The spec says that this should be returned from XHR in getAllResponseHeaders [2] but I don't think XHR actually returns this string there. Please can someone help point me to where this is required? If it isn't exposed anywhere I think we can remove this section. Thanks, Adrian [1] http://dev.w3.org/2006/webapi/FileAPI/#ProtocolName [2] http://dev.w3.org/2006/webapi/FileAPI/#ProtocolExamples
[FileAPI] Length of the opaque string for blob URLs
The current spec requires the opaque string in Blob URLs to be at least 36 characters in length [1]. Our implementation doesn't currently use a UUID and the length of the string is shorter than 36 characters. While I have no problem with the recommendation to use UUIDs in the spec, since it isn't a MUST I wonder whether the length requirement needs to be a MUST. Could we relax this requirement? Thanks, Adrian [1] http://dev.w3.org/2006/webapi/FileAPI/#OpaqueStringDiscussion
[FileAPI] Remove readAsBinaryString?
Another topic that came up at TPAC was readAsBinaryString [1]. This method predates support for typed arrays in the FileAPI and allows binary data to be read and stored in a string. This is an inefficient way to store data now that we have ArrayBuffer and we'd like to not support this method. At TPAC I proposed that we remove readAsBinaryString from the spec and there was some support for this idea. I'd like to propose that we change the spec to remove this. Thanks, Adrian. [1] http://dev.w3.org/2006/webapi/FileAPI/#readAsBinaryString
Re: [FileAPI] Remove readAsBinaryString?
Seems quite reasonable to me. We've got data URL strings for people who need inefficiency (or portable strings). On Dec 13, 2011, at 4:52 PM, Adrian Bateman adria...@microsoft.com wrote: Another topic that came up at TPAC was readAsBinaryString [1]. This method predates support for typed arrays in the FileAPI and allows binary data to be read and stored in a string. This is an inefficient way to store data now that we have ArrayBuffer and we'd like to not support this method. At TPAC I proposed that we remove readAsBinaryString from the spec and there was some support for this idea. I'd like to propose that we change the spec to remove this. Thanks, Adrian. [1] http://dev.w3.org/2006/webapi/FileAPI/#readAsBinaryString
[FileAPI] createObjectURL isReusable proposal
At TPAC [1,2] I described our proposal for adding an isReusable flag to createObjectURL. A common pattern we have seen is the need for a blob URL for a single use (for example, loading into an img element) and then revoking the URL. This requires a fair amount of boilerplate code to handle the load/error events. createObjectURL is modified as follows: static DOMString createObjectURL(Blob blob, [optional] bool isReusable); The value of isReusable defaults to true if it is not supplied and this results in the behaviour documented for File API today. However, if you supply false for the flag then the first dereference of the URL revokes it. This means that you can do something like: imgElement.src = URL.createObjectURL(blob,false) and not worry about having to call URL.revokeObjectURL to release the Blob. We have implemented this in experimental form in IE10 preview builds and it works well. There seemed to be a fair amount of support at TPAC and we're hoping this will be adopted in the File API spec. Thanks, Adrian. [1] http://www.w3.org/2011/11/01-webapps-minutes.html#item02 [2] http://pages.adrianba.net/w3c/FilesAndStreams.pdf
Re: [FileAPI] Remove readAsBinaryString?
+1 though it won't likely go away from implementations as easily. On Dec 13, 2011, at 8:22 PM, Charles Pritchard ch...@jumis.com wrote: Seems quite reasonable to me. We've got data URL strings for people who need inefficiency (or portable strings). On Dec 13, 2011, at 4:52 PM, Adrian Bateman adria...@microsoft.com wrote: Another topic that came up at TPAC was readAsBinaryString [1]. This method predates support for typed arrays in the FileAPI and allows binary data to be read and stored in a string. This is an inefficient way to store data now that we have ArrayBuffer and we'd like to not support this method. At TPAC I proposed that we remove readAsBinaryString from the spec and there was some support for this idea. I'd like to propose that we change the spec to remove this. Thanks, Adrian. [1] http://dev.w3.org/2006/webapi/FileAPI/#readAsBinaryString
Re: [FileAPI] createObjectURL isReusable proposal
I've seen the same pattern, though mysteriously, running a revoke in the same loop still allows the image to be loaded. I may have made a mistake in reading those source files or it may be a special quirk in the order of event loading. However this is approached, I think it should have firm roots in the operation of the event loop. On Dec 13, 2011, at 4:52 PM, Adrian Bateman adria...@microsoft.com wrote: At TPAC [1,2] I described our proposal for adding an isReusable flag to createObjectURL. A common pattern we have seen is the need for a blob URL for a single use (for example, loading into an img element) and then revoking the URL. This requires a fair amount of boilerplate code to handle the load/error events. createObjectURL is modified as follows: static DOMString createObjectURL(Blob blob, [optional] bool isReusable); The value of isReusable defaults to true if it is not supplied and this results in the behaviour documented for File API today. However, if you supply false for the flag then the first dereference of the URL revokes it. This means that you can do something like: imgElement.src = URL.createObjectURL(blob,false) and not worry about having to call URL.revokeObjectURL to release the Blob. We have implemented this in experimental form in IE10 preview builds and it works well. There seemed to be a fair amount of support at TPAC and we're hoping this will be adopted in the File API spec. Thanks, Adrian. [1] http://www.w3.org/2011/11/01-webapps-minutes.html#item02 [2] http://pages.adrianba.net/w3c/FilesAndStreams.pdf
Re: Proposed Specification for find/findAll/matches
This proposal looks really good and matches my expectations. Yehuda Katz (ph) 718.877.1325 On Tue, Dec 13, 2011 at 3:53 AM, Lachlan Hunt lachlan.h...@lachy.id.auwrote: On 2011-12-12 17:57, Boris Zbarsky wrote: On 12/12/11 6:07 AM, Lachlan Hunt wrote: Given a selector list as input to the method, trim whitespace and then for each complex selector, run the first step that applies: (Note: if the selector list is , then there are 0 complex selectors in the list and the following doesn't run) | 1. Otherwise, if the complex selector begins with any combinator This needs to be defined better. complex selector can't begin with a combinator, per its definition. For the purposes of this API, I think the spec needs to define a modified syntax for a DOM Selector, which is similar to, but slightly different from a regular selector. The grammar production would be: dom_selectors_group : dom_selector [ COMMA S* dom_selector ]* ; dom_selector : [ combinator ]? selector ; Where the productions for combinator and selector are defined in Selectors. The spec would then define that the parameter accepts a group of DOM selectors that matches that grammar. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [FileAPI] createObjectURL isReusable proposal
On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman adria...@microsoft.com wrote: At TPAC [1,2] I described our proposal for adding an isReusable flag to createObjectURL. A common pattern we have seen is the need for a blob URL for a single use (for example, loading into an img element) and then revoking the URL. This requires a fair amount of boilerplate code to handle the load/error events. createObjectURL is modified as follows: static DOMString createObjectURL(Blob blob, [optional] bool isReusable); The value of isReusable defaults to true if it is not supplied and this results in the behaviour documented for File API today. However, if you supply false for the flag then the first dereference of the URL revokes it. Could the argument have inverted semantics? Optional arguments that default to true are a bit confusing. Usually omitted boolean arguments default to false. This means that you can do something like: imgElement.src = URL.createObjectURL(blob,false) and not worry about having to call URL.revokeObjectURL to release the Blob. We have implemented this in experimental form in IE10 preview builds and it works well. There seemed to be a fair amount of support at TPAC and we're hoping this will be adopted in the File API spec. Thanks, Adrian. [1] http://www.w3.org/2011/11/01-webapps-minutes.html#item02 [2] http://pages.adrianba.net/w3c/FilesAndStreams.pdf -- Simon Pieters Opera Software
Barewords in on* attributes, redux (also, find() and company)
John Jensen here at Mozilla has been doing some web crawling trying to find what barewords are used in on* attributes. What I have so far as a result is a list of about 1.7 million barewords used across several tens of thousands of pages. If people are interested in the exact methodology, I can probably get a description. I'm working on making sure that it's ok for me to post the data in its entirety so you can all look as well. Assuming it is (very likely), where's a good place to stick a 7MB compressed file? In any case, for this particular data set there are no hits on findAll or matches (good!), but there are two hits on find as a bareword in an on* attribute. Specifically: 1) http://otc-pif.rbc.ru/pif_calculator/calculator.jsp has onclick=find(document.getElementById(current + 'List').children, searchString.value) 2) http://bookmark.people.com.cn/index.html has onclick=find() These would both obviously get broken by the proposed find() API, unless we actually do some sort of workaround for this problem... -Boris
