Re: Widgets ApplicationCache (was: Standards for Web applications on mobile devices: August 2011 updates)
Le samedi 17 septembre 2011 à 10:30 +0100, Marcos Caceres a écrit : shortcut: if you want to (incorrectly, IMO) continue to lump widgets and app cache, then do so making it clear that this is just one of the use cases for widgets and certainly NOT the primary use case… My document focuses on technologies available to build client-side Web applications for mobile devices; the 52 specifications that the document mentions have all use cases that go well beyond that use case, but I don't think the document would win in usefulness or clarity by stating so for each of these specifications. And please add a separate section just for Widgets in your document that explains the other cases. If by the other cases, you mean: They have been used as server side applications, standalone applications, daemons, and as an extension format. Server-side applications, daemons, and browser extensions are clearly out of scope of the document, so I don't think it would make sense to list them. I agree that there are similarities and overlap for this *one* use case; but again, the use cases of Widgets are far greater than ApplicationCache. To lump them together waters Widgets down to a confusing equivalent to AppCache. The document specifically says that the two approaches are complementary (not redundant), and summarizes what the two technologies provide. I don't see why having them in the same section would mean they're equivalent (again, no more than having SVG and CSS in the same section would mean they're equivalent). If you think the current description doesn't convey clearly enough the differences between the two approaches, I'll be happy to review a better description (either in reply to this mail, or directly in the wiki http://www.w3.org/wiki/Standards_for_Web_Applications_on_Mobile ). Dom
[Bug 14214] New: missing definition of Transferable
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14214 Summary: missing definition of Transferable Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Web Workers (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: gl...@skynav.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org the type 'Transferable' is referred to in the definitions of DedicatedWorkerGlobalScope (4.2.2) and Worker (4.8.2); however, no definition or reference to a definition of this type is provided -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: Widgets ApplicationCache (was: Standards for Web applications on mobile devices: August 2011 updates)
On Monday, September 19, 2011 at 10:06 AM, Dominique Hazael-Massieux wrote: Le samedi 17 septembre 2011 à 10:30 +0100, Marcos Caceres a écrit : shortcut: if you want to (incorrectly, IMO) continue to lump widgets and app cache, then do so making it clear that this is just one of the use cases for widgets and certainly NOT the primary use case… My document focuses on technologies available to build client-side Web applications for mobile devices; the 52 specifications that the document mentions have all use cases that go well beyond that use case, but I don't think the document would win in usefulness or clarity by stating so for each of these specifications. That's fine, but please make that clear - it is not clear enough in the introduction. I.e., just adapt what you say above and put it in the introduction: [[ This document focuses on technologies that may aid in the development of client-side Web applications for mobile devices; the specifications that the document mentions have all use cases that go well beyond the mobile application use case. For example, in addition to aiding in the development of client-side Web applications for mobile devices, W3C Widgets have been used as server side-applications, standalone applications, daemons, and as a Browser extension format. Similarly, [SVG] ... ]] You can fill out the SVG bit or pick some other technology. And please add a separate section just for Widgets in your document that explains the other cases. If by the other cases, you mean: They have been used as server side applications, standalone applications, daemons, and as an extension format. Server-side applications, daemons, and browser extensions are clearly out of scope of the document, so I don't think it would make sense to list them. With a more clear understanding of what you are trying to achieve, I agree. I agree that there are similarities and overlap for this *one* use case; but again, the use cases of Widgets are far greater than ApplicationCache. To lump them together waters Widgets down to a confusing equivalent to AppCache. The document specifically says that the two approaches are complementary (not redundant), and summarizes what the two technologies provide. I don't see why having them in the same section would mean they're equivalent (again, no more than having SVG and CSS in the same section would mean they're equivalent). If you think the current description doesn't convey clearly enough the differences between the two approaches, I'll be happy to review a better description (either in reply to this mail, or directly in the wiki http://www.w3.org/wiki/Standards_for_Web_Applications_on_Mobile ). Dom
[Bug 14218] New: Check CharData when serializing Text
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14218 Summary: Check CharData when serializing Text Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DOM Parsing and Serialization AssignedTo: ms2...@gmail.com ReportedBy: sim...@opera.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org http://html5.org/specs/dom-parsing.html#concept-serialize-xml doesn't check for CharData -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [widgets] Proposal to publish Widget Requirements and Widget Landscape docs as Working Group Notes; deadline Sep 23
Hi Marcos, On 9/16/11 10:14 AM, ext Marcos Caceres wrote: On Friday, 16 September 2011 at 20:04, Arthur Barstow wrote: Marcos, All, To clearly state that WebApps' work on the Widget Requirements and Widget Landscape documents has ended, I propose they be published as Working Group Notes: http://www.w3.org/TR/widgets-land/ http://www.w3.org/TR/widgets-reqs/ I think only the requirements should be published, because it was actually pretty useful in informing the standards development process. It's actually a pretty good document, if I do say so myself :) FYI, there is some precedence for publishing Requirements docs as Recommendations (e.g. OWL UCs and Reqs) . If we want to go that route, it would presumably mean publishing a LC, skipping CR (not applicable for this spec) and then going to PR and REC. WDYT? Too much make work? The landscape document was just created to inform the standardisation process of what was considered best practice at the time. If it's a W3C requirement that it be published as a WG Note, then it should be published as is (i.e., I don't wanna do any work on it unless I really have to). I don't feel real strongly here (and I will check with PLH on the publishing requirements). Publishing a WG Note does make a clear statement that work on the spec has stopped. We could also update the SotD which is quite old (e.g. still points to the appformats lists). [BTW, I would be willing to help with the edits.] -AB
[Bug 14220] New: In reply to comment #0) Every browser that I know of can have two web pages open at once. Those 2 web pages both have a DOM, they don't share a DOM. Some browsers implement
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14220 Summary: In reply to comment #0) Every browser that I know of can have two web pages open at once. Those 2 web pages both have a DOM, they don't share a DOM.Some browsers implement this as 2 different processes, some as 2 threads. This is where you're m Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Web Workers (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://www.w3.org/TR/2011/WD-workers-20110901/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: In reply to comment #0) Every browser that I know of can have two web pages open at once. Those 2 web pages both have a DOM, they don't share a DOM.Some browsers implement this as 2 different processes, some as 2 threads. This is where you're mistaken.Some browsers (Firefox?) have one thread for all pages. They cannot support two threads both accessing DOMs, even different DOMs, because their implementation is not thread-safe at all. Different pages can both access DOMs because they're actually on the same thread. (I think.) - You may be right about the single thread. Also it appears that Firefox does not allow one to start another instance of it as another process. Even with 3 running, there is only a single firefox in the process list. In such a situation, I would recommend that Firefox be changed rather than the spec. Posted from: 199.89.158.130 User agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0) -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [widgets] Proposal to publish Widget Requirements and Widget Landscape docs as Working Group Notes; deadline Sep 23
On Monday, September 19, 2011 at 2:08 PM, Arthur Barstow wrote: FYI, there is some precedence for publishing Requirements docs as Recommendations (e.g. OWL UCs and Reqs) . If we want to go that route, it would presumably mean publishing a LC, skipping CR (not applicable for this spec) and then going to PR and REC. WDYT? Too much make work? I think it's make work (though I would have argued for this a few years ago). I think we should keep /TR/ for specifications that target user agents. It might also be too controversial to try to push a requirement document to REC independently of the specifications that meet those requirements. The landscape document was just created to inform the standardisation process of what was considered best practice at the time. If it's a W3C requirement that it be published as a WG Note, then it should be published as is (i.e., I don't wanna do any work on it unless I really have to). I don't feel real strongly here (and I will check with PLH on the publishing requirements). Publishing a WG Note does make a clear statement that work on the spec has stopped. We could also update the SotD which is quite old (e.g. still points to the appformats lists). [BTW, I would be willing to help with the edits.] Ok, lets see what PLH says. Thanks for your offer of help; it's very much appreciated.
Re: [editing] Using public-webapps for editing discussion
Aryeh - coming back to your question below ... Since you are the Chair of the HTML Editing APIs CG [CG], would you please explain what you see as the relationship between the CG and WebApps vis-à-vis the Editing spec? In particular, what role(s) do the CG and WG have? For example [1] indicates the CG already has a mail list (public-editing) so when would it be used versus public-webapps? -Thanks, AB [CG] http://www.w3.org/community/editing/ On 9/13/11 4:27 PM, ext Aryeh Gregor wrote: For the last several months, I was working on a new specification, which I hosted on aryeh.name. Now we've created a new Community Group at the W3C to host it: http://aryeh.name/spec/editing/editing.html http://www.w3.org/community/editing/ Things are still being worked out, but one issue is what mailing list to use for discussion. I don't want to create new tiny mailing lists -- I think we should reuse some existing established list where the stakeholders are already present. Previously I was using the whatwg list, but as a token of good faith toward the W3C, I'd prefer to switch to public-webapps, even though my spec is not a WebApps WG deliverable. (If it ever does move to a REC track spec, though, which the Community Group process makes easy, it will undoubtedly be in the WebApps WG.) Does anyone object to using this list to discuss the editing spec?
Re: [editing] Using public-webapps for editing discussion
On Mon, 19 Sep 2011 18:48:04 +0200, Arthur Barstow art.bars...@nokia.com wrote: Aryeh - coming back to your question below ... Since you are the Chair of the HTML Editing APIs CG [CG], would you please explain what you see as the relationship between the CG and WebApps vis-à-vis the Editing spec? In particular, what role(s) do the CG and WG have? For example [1] indicates the CG already has a mail list (public-editing) so when would it be used versus public-webapps? I think we do not want to use public-editing at all and replace it with public-webapps. I believe the system in place at the moment for CGs does not allow that, but it can be done behind the scenes and is intended to work in such a way in the future I am told. -- Anne van Kesteren http://annevankesteren.nl/
Re: [editing] Using public-webapps for editing discussion
On Mon, Sep 19, 2011 at 12:48 PM, Arthur Barstow art.bars...@nokia.com wrote: Aryeh - coming back to your question below ... Since you are the Chair of the HTML Editing APIs CG [CG], would you please explain what you see as the relationship between the CG and WebApps vis-à-vis the Editing spec? In particular, what role(s) do the CG and WG have? For example [1] indicates the CG already has a mail list (public-editing) so when would it be used versus public-webapps? I do not intend to use any of the mailing lists created for the CG at all. We don't need our own mailing lists -- it will just fragment discussion. The editing spec is too small to deserve its own list. If it turns out we can use public-webapps, I'll ask that the links on the CG page point only to that, and that the CG lists be deleted. If the CG lists have to continue to exist for whatever reason, I'll make sure to tell anyone who uses them to use public-webapps instead. If we can't use public-webapps, then I'll continue using the whatwg list instead. I won't use editing-only lists regardless.
Re: [editing] Using public-webapps for editing discussion
On Mon, Sep 19, 2011 at 12:48 PM, Arthur Barstow art.bars...@nokia.com wrote: Since you are the Chair of the HTML Editing APIs CG [CG], would you please explain what you see as the relationship between the CG and WebApps vis-à-vis the Editing spec? In particular, what role(s) do the CG and WG have? I notice you asked a more general question here too that I didn't answer. My take is that the CG will be the group that publishes the editing spec for the foreseeable future. However, all discussion and development should occur in preexisting, established fora, preferably in the W3C. This means using fora that are specific to particular Working Groups, such as public-webapps, even though those Working Groups aren't formally involved in developing the editing spec. So currently, I don't see the WebApps WG as having any official role in developing the editing spec. I'd only like to be able to use its discussion list, since a lot of interested parties are already subscribed. Eventually, if it turns out to be necessary to move the spec to the REC track (although I hope it's not), I expect that will be at the WebApps WG, given its charter. But that's not an immediate consideration.
[Bug 14069] Split up conformance tests into manageable chunks
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14069 Aryeh Gregor a...@aryeh.name changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Aryeh Gregor a...@aryeh.name 2011-09-19 18:15:30 UTC --- https://dvcs.w3.org/hg/editing/rev/b47a9462 Usable here: http://aryeh.name/spec/editing/conformancetest/splitruntest.html -- Configure bugmail: http://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 14063] Get runtest.html working in IE, and preferably Opera
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14063 Aryeh Gregor a...@aryeh.name changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Aryeh Gregor a...@aryeh.name 2011-09-19 21:01:34 UTC --- https://dvcs.w3.org/hg/editing/rev/ea6a5d169a17 https://dvcs.w3.org/hg/editing/rev/4a58a50f456c Tests now work in Opera 11.50 and IE10PP2. They sort of work in IE9, but it throws lots of weird exceptions, so I won't use it. The serialization errors are still there, but good enough for now. -- Configure bugmail: http://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 13938] Explicitly allow UAs to let the user execute commands without author intervention
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13938 Aryeh Gregor a...@aryeh.name changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Aryeh Gregor a...@aryeh.name 2011-09-19 21:23:41 UTC --- https://dvcs.w3.org/hg/editing/rev/7dc85d546add I didn't allow any special way for authors to override it at this point. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [widgets] Proposal to publish Widget Requirements and Widget Landscape docs as Working Group Notes; deadline Sep 23
On 9/19/11 10:54 AM, ext Marcos Caceres wrote: On Monday, September 19, 2011 at 2:08 PM, Arthur Barstow wrote: FYI, there is some precedence for publishing Requirements docs as Recommendations (e.g. OWL UCs and Reqs) . If we want to go that route, it would presumably mean publishing a LC, skipping CR (not applicable for this spec) and then going to PR and REC. WDYT? Too much make work? I think it's make work (though I would have argued for this a few years ago). I think we should keep /TR/ for specifications that target user agents. It might also be too controversial to try to push a requirement document to REC independently of the specifications that meet those requirements. The landscape document was just created to inform the standardisation process of what was considered best practice at the time. If it's a W3C requirement that it be published as a WG Note, then it should be published as is (i.e., I don't wanna do any work on it unless I really have to). I don't feel real strongly here (and I will check with PLH on the publishing requirements). Publishing a WG Note does make a clear statement that work on the spec has stopped. We could also update the SotD which is quite old (e.g. still points to the appformats lists). [BTW, I would be willing to help with the edits.] Ok, lets see what PLH says. Thanks for your offer of help; it's very much appreciated. PLH says that ideally every spec ends as a WG Note or a Recommendation but in practice groups need to consider other factors. In the case of the Landscape doc, which was by definition (or at least by title) transient, so let's just drop it (and not publish it as a WG Note). So, the proposal for the Landscape doc is amended: the proposal is to formally stop working on the Landscape document and to move it to PubStatus' Specs NO Longer Active table: http://www.w3.org/2008/webapps/wiki/PubStatus#Specs_NO_Longer_Active If anyone objects to that, please reply by September 23 and understand that it would mean that you must do the editing work to produce a WG Note. (The proposal to publish the Requirements doc as WG Note remains unchanged.) -AB
[Bug 13777] The WebSocket protocol draft (hybi-10) restricts the value of subprotocols as follows: The elements that comprise this value MUST be non- empty strings with characters in the ran
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13777 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Ian 'Hixie' Hickson i...@hixie.ch 2011-09-19 22:33:53 UTC --- I just referenced the WebSocket protocol. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Adding Web Intents to the Webapps WG deliverables
I'm forwarding this on behalf of a colleague whose message seems caught up in a moderation queue. Apologies if it results in a duplicate message for anyone. -- Forwarded message -- From: James Hawkins jhawk...@google.com Date: Mon, Sep 19, 2011 at 1:27 PM Subject: Adding Web Intents to the Webapps WG deliverables To: public-webapps@w3.org I am the tech lead for the team designing and implementing Web Intents [1] for Chrome at Google. Web Intents is a web platform feature modeled after the similarly named feature in Android OS. Web Intents enables client sites to request high-level functionality, e.g. share, edit, pick, upload, auth, from an unknown (to the client) provider. The UA enumerates the list of registered providers that the user has already accepted as Intent handlers, allowing the user to pick which provider she wants to use for the particular action. This feature is not a panacea, nor do we envision it as a 'meta API'; however, the use cases we've focused on will make web apps much more connected and useful for users. Take the NASCAR problem: with Web Intents, publishers can get rid of maintaining an ever-growing list of 'share' providers, replacing them with one share button that kicks off the 'share' action. The user only sees the sites that she actively uses. Note: we're actively working with Mozilla on the API, and the draft I have prepared has been agreed upon by both vendors. I've read through the Webapps charter, and I believe Web Intents fits the goals and scope of the WG. Goals * Promote universal access to Web applications across a wide range of devices. - Web Intents can be implemented in browsers on all devices, and more importantly, the feature is a perfect conduit for hooking into platform functionality (Android Intents, iOS API, a scalable registerProtocolHandler). * Promote creation of tutorials and other educational material. - Check out http://examples.webintents.org where we have example clients/providers of Web Intents using a JS shim that works across all current browsers. - The action string in the API is suggested to be a URL pointing to documentation for the action, e.g., http://webintents.org/share is both the string for the 'share' action and the URL of the documentation for said action. Scope * Markup vocabularies for describing and controlling client-side application behavior. - Web Intents provides an intent tag that allows provider sites to declare which intent actions they handle. * Programming interfaces for client-side development: platform interaction. - As stated above, this feature can easily be extended to hook into the platform to, say, allow the UA to notify providers of platform events or data sources, e.g., plugging in a camera. The developers of this API, from both Mozilla and Google, believe Webapps is the right home for Web Intents. I'd like to open discussion on the topic and get your feedback. Ultimately we'd like to take the next steps towards getting Web Intents officially out in the open, actively developed by the larger Webapps community. Thanks, James Hawkins [1] http://dev.chromium.org/developers/design-documents/webintentsapi
Re: New tests submitted by Microsoft for WebApps specs
On Tue, Sep 13, 2011 at 6:26 PM, Adrian Bateman adria...@microsoft.comwrote: WebWorkers (51 tests/assertions) Changeset: http://dvcs.w3.org/hg/webapps/rev/7b0ba70f69b6 Tests: http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/ * We believe the tests are all accurate but look forward to wider review from the group. IE10 PP3 does not pass all the tests and we are working to fix the bugs that cause failures. Web Worker test issues: issue 1: WorkerGlobalScope_ErrorEvent_*.htm uses the onerror function and expected to get an error event but instead it should get 3 arguments. See http://www.whatwg.org/specs/web-apps/current-work/complete/workers.html#runtime-script-errors-0 and http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#report-the-error issue 2: postMessage_clone_port_error.htm expects to get INVALID_STATE_ERR but should expect to get DATA_CLONE_ERR. http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#posting-messages
Re: Adding Web Intents to the Webapps WG deliverables
Why not just improve both navigator.registerContentHandler and navigator.registerProtocolHandler? In particular, why are intents registered via a new HTML element rather than an API? How do you unregister? How do you determine if the intent was registered or not? How do you conditionally register (e.g. once the user has paid for the service)? How does an already-open page get to handle an action? e.g. say GMail wants to handle the share intent, and the user already has GMail open, and the user clicks a share button on Flickr. How does the existing GMail instance get the notification? Why are the verbs URLs? Why are some verbs hard-coded into the API? How are types matched? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Adding Web Intents to the Webapps WG deliverables
Should Paul Kinlan be Cc'd on this? His concept work is helpful. On Sep 19, 2011, at 8:53 PM, Ian Hickson i...@hixie.ch wrote: Why not just improve both navigator.registerContentHandler and navigator.registerProtocolHandler? In particular, why are intents registered via a new HTML element rather than an API? How do you unregister? How do you determine if the intent was registered or not? How do you conditionally register (e.g. once the user has paid for the service)? How does an already-open page get to handle an action? e.g. say GMail wants to handle the share intent, and the user already has GMail open, and the user clicks a share button on Flickr. How does the existing GMail instance get the notification? Why are the verbs URLs? Why are some verbs hard-coded into the API? How are types matched? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Adding Web Intents to the Webapps WG deliverables
+Paul Kinlan, Greg Billock - from Google team. +Mike Hanson, Ben Adida - from Mozilla team. On Mon, Sep 19, 2011 at 9:25 PM, Charles Pritchard ch...@jumis.com wrote: Should Paul Kinlan be Cc'd on this? His concept work is helpful. On Sep 19, 2011, at 8:53 PM, Ian Hickson i...@hixie.ch wrote: Why not just improve both navigator.registerContentHandler and navigator.registerProtocolHandler? In particular, why are intents registered via a new HTML element rather than an API? How do you unregister? How do you determine if the intent was registered or not? How do you conditionally register (e.g. once the user has paid for the service)? How does an already-open page get to handle an action? e.g. say GMail wants to handle the share intent, and the user already has GMail open, and the user clicks a share button on Flickr. How does the existing GMail instance get the notification? Why are the verbs URLs? Why are some verbs hard-coded into the API? How are types matched? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Adding Web Intents to the Webapps WG deliverables
I am the tech lead for the team designing and implementing Web Intents [1] for Chrome at Google. Web Intents is a web platform feature modeled after the similarly named feature in Android OS. Web Intents enables client sites to request high-level functionality, e.g. share, edit, pick, upload, auth, from an unknown (to the client) provider. The UA enumerates the list of registered providers that the user has already accepted as Intent handlers, allowing the user to pick which provider she wants to use for the particular action. This feature is not a panacea, nor do we envision it as a 'meta API'; however, the use cases we've focused on will make web apps much more connected and useful for users. Take the NASCAR problem: with Web Intents, publishers can get rid of maintaining an ever-growing list of 'share' providers, replacing them with one share button that kicks off the 'share' action. The user only sees the sites that she actively uses. Note: we're actively working with Mozilla on the API, and the draft I have prepared has been agreed upon by both vendors. I've read through the Webapps charter, and I believe Web Intents fits the goals and scope of the WG. Goals * Promote universal access to Web applications across a wide range of devices. - Web Intents can be implemented in browsers on all devices, and more importantly, the feature is a perfect conduit for hooking into platform functionality (Android Intents, iOS API, a scalable registerProtocolHandler). * Promote creation of tutorials and other educational material. - Check out http://examples.webintents.org where we have example clients/providers of Web Intents using a JS shim that works across all current browsers. - The action string in the API is suggested to be a URL pointing to documentation for the action, e.g., http://webintents.org/share is both the string for the 'share' action and the URL of the documentation for said action. Scope * Markup vocabularies for describing and controlling client-side application behavior. - Web Intents provides an intent tag that allows provider sites to declare which intent actions they handle. * Programming interfaces for client-side development: platform interaction. - As stated above, this feature can easily be extended to hook into the platform to, say, allow the UA to notify providers of platform events or data sources, e.g., plugging in a camera. The developers of this API, from both Mozilla and Google, believe Webapps is the right home for Web Intents. I'd like to open discussion on the topic and get your feedback. Ultimately we'd like to take the next steps towards getting Web Intents officially out in the open, actively developed by the larger Webapps community. Thanks, James Hawkins [1] http://dev.chromium.org/developers/design-documents/webintentsapi
