From 58f2ca077de43b55a15f05b4e55d30c9059fc16b Mon Sep 17 00:00:00 2001 From: Marcos Caceres Date: Wed, 6 Nov 2013 10:59:29 +0000 Subject: [PATCH] first round of editorial fixes (closes #21) --- index.html | 125 ++++++++++++++++++++++++----------------------------- 1 file changed, 56 insertions(+), 69 deletions(-) diff --git a/index.html b/index.html index 039a8cc..a4b5b5f 100644 --- a/index.html +++ b/index.html @@ -2,13 +2,18 @@ - Core Mobile Web Platform — 2012 + Core Mobile Web Platform @@ -54,66 +59,48 @@
- The W3C Core Mobile Web Platform Community Group was established with the objective of helping to make the Web a compelling platform for developing modern mobile applications. The motivation for that is the widespread view that the Web does not represent a compelling platform for mobile applications today. + The purpose of the document is to promote understanding of which areas of Web technology are in need of development to better support the use of Web applications on mobile devices. It aims to encourage prioritization of those areas for standardization (specification, implementation, testing, and royalty free commitment). - This document presents a small number of simple mobile Web application use cases. It goes on to list features that the underlying mobile Web platform needs to offer to support those use cases. It then lists technology standards (primarily W3C Recommendations) that describe those features - and also notes the current state of development of such specifications, noting also where such specification do not at present exist. - - The purpose of the document is to promote understanding of which areas of Web technology are in need of development, and to encourage prioritization of those areas for specification, implementation and testing. - - Other aspects of the Community Group's work, which includes the collation and specification of test suites to assess conformance to referenced standards, and the specification of a framework within which such conformance testing might be assessed are referenced. + In order to do the above, this document presents a small number of user stories from which a set of requirement for the Web platform are derived. It goes on to list features that the underlying Web platform needs to offer to support those user stories. It then lists specifications that provide those features - and also notes the current state of development of such specifications, noting also where such specification do not at present exist.
- Comments on this document are not only welcomed but are actively solicited and should be made on the [public-coremob@w3.org mailing list](http://lists.w3.org/Archives/Public/public-coremob/). The source code is available on [GitHub](https://github.com/coremob/coremob-2012). + This is work in progress.
Introduction ============ - -Quoting from its [charter](http://www.w3.org/community/coremob/charter/): - -> The goal of the Core Mobile Web Platform (Coremob) Community Group (CG) is to accelerate the adoption of the Mobile Web as a compelling platform for the development of modern mobile Web applications. In order to achieve this mission, the CG brings developers, equipment manufacturers, browser vendors, operators and other relevant members of the industry together to: -> 1. Agree on core features developers can depend on. These will be defined by reference to a variety of other specifications from the W3C and other standards bodies. -> 1. Compile related conformance test suites. -> 1. Provide to W3C (and non-W3C) groups use cases, scenarios, and other input to drive successful mobile deployment. +Developers should be able to rely upon a set of Web technologies being consistently present and interoperably implemented across a wide range of browsers. -This document is the initial output of the Community Group. Its focus is items 1 and 3 from its charter above. +Specifications do not advance at a similar rate and are not necessarily of equally widespread utility for particular application use cases. In addition, some depend on others. This document is a description of a subset of Web platform technologies, and provides for a limited, or base set of such use cases. -The following sections serve to contextualize the role of this document against the CG charter. ### Audience -The primary audience for this document is standardization groups within the W3C as well as equipment manufacturers and browser vendors. The CG also intends it to be of interest to others in its chartered constituency, especially developers, for feedback on the selection of use cases and the derivation of technology requirements from those use cases. - -### Goals - -In respect of Coremob Charter item 1. above, developers should be able to rely upon a set of Web technologies being consistently present and interoperably implemented across a wide range of browsers. - -Technology specifications do not advance at a similar rate and are not necessarily of equally widespread utility for particular application use cases. In addition, some depend on others. This document is a description of a subset of Web platform technologies, and provides for a limited, or base set of such use cases. +The primary audience for this document is standardization groups within the W3C as well as equipment manufacturers and browser vendors. The IG also intends it to be of interest to others in its chartered constituency, especially developers, for feedback on the selection of use cases and the derivation of technology requirements from those use cases. -The CG may go on to produce a number of further descriptions of subsets of Web platform technology specifications which will provide for increasingly sophisticated application use cases. ### Methodology -The use cases chosen reflect a selection of popular applications that have been created using "native" techniques. Although the chosen set of use cases is limited, and the functionality implied by them is (relatively speaking) simple, the set of functionalities is nonetheless described as being "aspirational" because it goes beyond the state of implementation by most current browsers, and indeed goes beyond the current state of specification of some of those features - see below [Aspirational nature of the document](#aspirational-nature-of-the-document) for a discussion of the aspirational aspect, as construed in this revision. +The use cases chosen reflect a selection of popular applications that have been created using "native" techniques. Although the chosen set of use cases is limited, and the functionality implied by them is (relatively speaking) simple, the set of functionalities is nonetheless described as being "aspirational" because it goes beyond the state of implementation by most current browsers, and indeed goes beyond the current state of specification of some of those features - see below [aspirational nature of the document](#aspirational-nature-of-the-document) for a discussion of the aspirational aspect, as construed in this revision. -Having identified features of the Web platform that are required to fulfill the use cases it is then possible to identify a set of technology specifications (or to note the absence of suitable specifications) that specify those features. +Having identified features of the Web platform that are required to fulfill the use cases it is then possible to identify a set of specifications (or to note the absence of suitable specifications) that specify those features. Further, having identified a set of specifications, it is then possible to identify a set of tests (or note the absence of such tests) that can be used to assess conformance with the identified specifications and also to propose a test environment in which those tests can be carried out. ### Purpose of this Document -This document, as mentioned above, sets out the initial limited set of use cases; it derives Web platform technology requirements from them and it identifies technology specifications, at various states of maturity, that fulfill those requirements. It does not identify tests or test suites that match those technology specifications. +This document sets out the initial limited set of user stories; it derives requirements for the Web platform and it identifies specifications that fulfill those requirements. It does not identify tests or test suites that match those specifications. -Since standardization work is required to complete the set of technologies required to fulfill the various use cases the document identifies, one of the purposes of the document is to point out that increased coordination between the groups that create standards would be beneficial in order to create a more coherent and pragmatically useful mobile Web application platform. +Since standardization work is required to address the various use cases the document identifies, one of the purposes of the document is to point out that increased coordination between the groups that create standards would be beneficial in order to create a more coherent and pragmatically useful mobile Web application platform. -The intention of this document and subsequent editions, in regard of developers, is to solicit feedback on the use cases and on specific technology areas that are problematic when used in a mobile context. Developers are especially encouraged to contribute to the work of the CG, since it is hoped that such participation will reduce future maintenance and development costs for them and will also provide a means by which developers' voices may be heard by constituencies that need to hear them. +The intention of this document and subsequent editions, in regard of developers, is to solicit feedback on the use cases and on specific technology areas that are problematic when used in a mobile context. Developers are especially encouraged to contribute to the work of the IG, since it is hoped that such participation will reduce future maintenance and development costs for them and will also provide a means by which developers' voices may be heard by constituencies that need to hear them. ### Aspirational nature of the document -To be clear, the CG is not expressing the judgment that it is not possible to use the Web platform to build a wide variety of applications that can be used in a mobile context. Indeed, there are applications that can be built on the Web platform that work well in a mobile delivery context. The group notes, though, that those applications are not usually specifically mobile in their use cases and tend to be similar in nature to applications that have desktop use cases as much as they have mobile use cases. +To be clear, the IG is not expressing the judgment that it is not possible to use the Web platform to build a wide variety of applications that can be used in a mobile context. Indeed, there are applications that can be built on the Web platform that work well in a mobile delivery context. The group notes, though, that those applications are not usually specifically mobile in their use cases and tend to be similar in nature to applications that have desktop use cases as much as they have mobile use cases. Further, the view that it is already practical to develop effective mobile Web applications is expressed with the caveat that there are many "quality of implementation" issues that developers may encounter. For example, the frame rate achievable when developing mobile games may not be sufficient, in some cases, and as another example the synchronization of playing sounds may not be adequate. @@ -121,13 +108,13 @@ Mobile devices often have capabilities (such as a camera) or circumstances of use (such as periods off line, or frequent periods with low bandwidth for data transfer) that make mobile both a more rewarding environment for creation of applications and a more difficult environment for such implementations too. -With the rapid increase in uptake of use of mobile devices, both in developed markets and in less developed markets (perhaps as the only means of Web access in those markets), the CG believes that closing the gap between what can be achieved using Web technology on mobile and what can be achieved using "native application implementations" needs to narrow, urgently. +With the rapid increase in uptake of use of mobile devices, both in developed markets and in less developed markets (perhaps as the only means of Web access in those markets), the IG believes that closing the gap between what can be achieved using Web technology on mobile and what can be achieved using "native application implementations" needs to narrow, urgently. -### Other aspects of the CG's work +### Other aspects of the IG's work -Other aspects of the CG's work, as mentioned in its charter, continue in parallel to the development of this document. Those activities include a "Gap analysis" of where there are existing test suites relevant to the technologies identified in this document, as well as discussion of a Test Framework within which to execute tests of the conformance of implementations of technologies identified here. +Other aspects of the IG's work, as mentioned in its charter, continue in parallel to the development of this document. Those activities include a "Gap analysis" of where there are existing test suites relevant to the technologies identified in this document, as well as discussion of a Test Framework within which to execute tests of the conformance of implementations of technologies identified here. -The CG's [Web site](http://www.w3.org/community/coremob/) and [Wiki](http://www.w3.org/community/coremob/wiki/) contain links to various aspects of the group's work. +The IG's [Web site](http://www.w3.org/community/coremob/) and [Wiki](http://www.w3.org/community/coremob/wiki/) contain links to various aspects of the group's work. ### Structure @@ -166,7 +153,7 @@ Take pictures in a remote area without network coverage ------------------------------------------------------- - Jenna is hiking in a remote area without network coverage. She takes high quality pictures using a Web application. The pictures are stored locally. She decides to post-process some of the pictures she took by applying ready made filters. She is able to continue taking pictures while the filters are applied. When she returns to an area with better network coverage, her pictures are updated to a remote server. While the upload is going on in the background she can continue taking pictures or can browse her previous shots to select the ones she wants to share with her friends. + Jenna is hiking in a remote area without network coverage. She takes high quality pictures using a Web application. The pictures are stored locally. She decides to post-process some of the pictures she took by applying ready made filters. She is able to continue taking pictures while the filters are applied. When she returns to an area with better network coverage, her pictures are synchronize with a remote server. While the upload is going on in the background she can continue taking pictures or can browse her previous shots to select the ones she wants to share with her friends. Derived requirements: , @@ -194,7 +181,7 @@ Play a 2D Game --------------- - Fantastic Rafaela Sis' is a game the goal of which is to save an imprisoned prince. This is done by navigating a character, Rafaela, across various levels from left to right. Each level consist of a series of obstacles and enemies that the player has to avoid (by jumping over, shooting, etc). The character is controlled by tilting the device. Consequently, the game must be locked in landscape mode to avoid auto-rotation of the viewport interfering with the game play. It has a soundtrack per level and various sound effects. + *Fantastic Rafaela Sis'* is a game the goal of which is to save an imprisoned prince. This is done by navigating a character, Rafaela, across various levels from left to right. Each level consist of a series of obstacles and enemies that the player has to avoid (by jumping over, shooting, etc). The character is controlled by tilting the device. Consequently, the game must be locked in landscape mode to avoid auto-rotation of the viewport interfering with the game play. It has a soundtrack per level and various sound effects. Derived requirements: , @@ -215,7 +202,7 @@ Read an online magazine ----------------------- - Jane likes to read the news on her commute to work. She uses a Web application on her tablet that she updates before leaving home. While on the subway, she is able to read the daily news, watch a video of the highlights of yesterday's football match and listen to the magazine's weekly political podcast. Jane is able to navigate through the application using the back and forward button of her browser. And when she finds an article she would like to share with her friend, Sam, she is able to copy and paste the URL into an email. + Jane likes to read the news on her commute to work. She uses a Web application on her tablet that she updates before leaving home. While on the subway, she is able to read the daily news, watch a video of the highlights of yesterday's football match and listen to the magazine's weekly political podcast. Jane is able to navigate through the application using the back and forward button of her browser. And when she finds an article she would like to share, she is able to copy and paste the URL into an email or other application. Derived requirements: , @@ -258,29 +245,29 @@ Derived Requirements ==================== -

Managing battery use and network connectivity (e.g. delay, throughput and cost) is an important concern on mobile devices. The CG thinks that agreement on what it is practical to measure and what actions developers might take in response to those measurements is not at a sufficiently advanced stage to posit requirements in this area.

+

Managing battery use and network connectivity (e.g. delay, throughput and cost) is an important concern on mobile devices. The IG thinks that agreement on what it is practical to measure and what actions developers might take in response to those measurements is not at a sufficiently advanced stage to posit requirements in this area.

The following requirements are derived from the use cases described in . General ------- -

A User Agent MUST support technology commonly available on desktop browsers, so that Web sites and applications designed for desktop are still usable on mobile.

+

A user agent MUST support the Web platform features available on desktop browsers, so that Web applications designed for desktop are still usable on mobile.

-

The User Agent MUST be able to display content specifically targeted at mobile devices.

+

The user agent MUST be able to display content specifically targeted at mobile devices.

-

It MUST be possible for the User Agent to download and display different content depending on device or User Agent properties such as screen size, pixel density, etc.

+

It MUST be possible for the user agent to download and display different content depending on device or user agent properties such as screen size, pixel density, etc.

-

The User Agent MUST support rich typography including using downloadable fonts.

+

The user agent MUST support rich typography including using downloadable fonts.

App-specific ------------ -

It MUST be possible to provide the User Agent with metadata a such as the application's name, icon, etc.

+

It MUST be possible to provide the user agent with metadata a such as the application's name, icon, etc.

It MUST be possible to make an application available off-line.

-

The User Agent MUST allow the application developer to define URLs for chosen resources (for example for bookmarking or sharing) and to manipulate session history for single page applications.

+

The user agent MUST allow the application developer to define URLs for chosen resources (for example for bookmarking or sharing) and to manipulate session history for single page applications.

It MUST be possible for Web application user interfaces to occupy all the screen space yet adapt to different screen sizes without leaving unused space or overflowing.

@@ -288,16 +275,16 @@

It MUST be possible to scroll smoothly through a large body of content.

-

A Web application might be designed to be used strictly in portrait or landscape mode. It MUST be possible to signal this preference to the User Agent.

+

A Web application might be designed to be used strictly in portrait or landscape mode. It MUST be possible to signal this preference to the user agent.

-

It MUST be possible for an application to signal to the User Agent that it wants to operate full screen and not inside the User Agent's chrome.

+

It MUST be possible for an application to signal to the user agent that it wants to operate full screen and not inside the user agent's chrome.

Storage ------- -

It MUST be possible to store files locally and retrieve them without requiring further permission from the user.

+

It MUST be possible to store resources locally and retrieve them without requiring further permission from the user.

-

It MUST be possible to asynchronously store and retrieve large, structured persistent data sets.

+

It MUST be possible to store and retrieve large, structured persistent data sets. This MUST NOT interrupt the ability of the user to interact with the application.

Multimedia ---------- @@ -324,7 +311,7 @@ Networking ---------- -

It MUST be possible to upload files to remote server on different origins asynchronously. Uploads SHOULD continue even if the user navigates to a different page.

+

It MUST be possible to upload files to remote server on different origins. Uploads SHOULD continue even if the user navigates to a different page.

`mailto:`, `tel:`, `sms:` and `mmsto:` URL schemes SHOULD allow the user to send an email, make a phone call, send an SMS or send an MMS using the appropriate application to do so.

@@ -333,11 +320,11 @@ This section lists existing specifications which address the requirements expressed in and notes their current state of standardization (progress along [W3C Rec Track](http://www.w3.org/2005/10/Process-20051014/tr.html#maturity-levels) is noted using conventional abbreviations). - The document [Standards for Web Applications on Mobile: current state and roadmap](http://www.w3.org/Mobile/mobile-web-app-state/) is regularly updated to reflect current status both of standardization and of implementation of many of the same standards. + The document [Standards for Web Applications on Mobile: current state and roadmap](http://www.w3.org/Mobile/mobile-web-app-state/) is regularly updated to reflect current status both of standardization and of implementation of many of the same standards. -

The CG has had frequent cause to discuss whether or not it needs to make reference to **the whole** of a referenced specification. In the course of such discussions it has frequently re-iterated that it is not its role to cherry-pick parts of the specifications produced by other groups. Equally, however, it has frequently noted that its use cases require only sub-sections of referenced specifications. The CG has observed that the WGs responsible for producing such specifications might choose to subset their work to advance speed of specification, modularity of testing and so on.

+

The IG has had frequent cause to discuss whether or not it needs to make reference to **the whole** of a referenced specification. In the course of such discussions it has frequently re-iterated that it is not its role to cherry-pick parts of the specifications produced by other groups. Equally, however, it has frequently noted that its use cases require only sub-sections of referenced specifications. The IG has observed that the WGs responsible for producing such specifications might choose to subset their work to advance speed of specification, modularity of testing, and so on.

-

The CG notes that simple interoperability of video and audio content is highly desirable. The CG also notes that considerations regarding such interoperability concern all aspects of the use of such content on the Web (and are not of more concern in mobile than elsewhere).

+

The IG notes that simple interoperability of video and audio content is highly desirable. The IG also notes that considerations regarding such interoperability concern all aspects of the use of such content on the Web (and are not of more concern in mobile than elsewhere).

Markup ------ @@ -425,10 +412,10 @@ - GeneralECMAScript, Edition 5.1 [[ECMA-262-51]]N/A + GeneralECMAScript, Edition 6 [[ECMA-262]]N/A DOM - DOM4 API [[DOM4]]WD + DOM API [[DOM]]WD DOM Level 3 Events [[DOM-LEVEL-3-EVENTS]]WD @@ -513,7 +500,7 @@ , and . - There is ongoing work to address each of those requirements within W3C as detailed below. The CG encourages these efforts. + There is ongoing work to address each of those requirements within W3C as detailed below. The IG encourages these efforts. Pointer events -------------- @@ -528,7 +515,7 @@ Application meta-data --------------------- - The multitude of existing formats to describe application meta-data () have been [listed](http://www.brucelawson.co.uk/2011/installable-web-apps-and-interoperability/) [elsewhere](http://blog.tobie.me/post/14262541286/app-manifests-an-anthology) already. The WebApps WG is [chartered](http://www.w3.org/2012/webapps/charter/Overview.html#deliverables) to work on this and has two related specs: Widget Packaging and Configuration [[WIDGETS]] (which has had little traction among the main vendors), and Web Application Manifest Format and Management APIs [[WEBAPPS-MANIFEST-API]] (which is still an early Editor's draft). Additionally, the combination of a number of [[HTML5]] features, such as the `title` element, `meta` application-name element and `link` icons element provides similar capabilities, yet this solution lacks sufficient comprehensiveness and cohesiveness to meet the requirements. + The multitude of existing formats to describe application meta-data () have been [listed](http://www.brucelawson.co.uk/2011/installable-web-apps-and-interoperability/) [elsewhere](http://blog.tobie.me/post/14262541286/app-manifests-an-anthology) already. The WebApps WG is [chartered](http://www.w3.org/2012/webapps/charter/Overview.html#deliverables) to work on this and has two related specs: Packaged Web Apps (Widgets) - Packaging and XML Configuration [[WIDGETS]] (which has gotten little traction among the main vendors), and Web Application Manifest Format and Management APIs [[WEBAPPS-MANIFEST-API]] (which is still an early Editor's draft). Additionally, the combination of a number of [[HTML5]] features, such as the `title` element, `meta` application-name element and `link` icons element provides similar capabilities, yet this solution lacks sufficient comprehensiveness and cohesiveness to meet the requirements. Offline ------- @@ -540,7 +527,7 @@ Screen Orientation ------------------ - A specification to fulfill is a deliverable of the WebApps WG. A first public Working Draft [[SCREEN-ORIENTATION]] was recently published by the WG. The CG applauds this effort and encourages the WG to explore other solutions such as a JavaScript API for [[CSS-ADAPTATION]] which already has an `orientation` property. + A specification to fulfill is a deliverable of the WebApps WG. A first public Working Draft [[SCREEN-ORIENTATION]] was recently published by the WG. The CG encourages the WG to explore other solutions such as a JavaScript API for [[CSS-ADAPTATION]] which already has an `orientation` property. Unaddressed requirements @@ -576,7 +563,7 @@ Performance of the `canvas` element ----------------------------------- - Implementors should pay attention to the performance characteristics of the `canvas` element which is particularly well suited for the development of 2D and isometric games. In order to meet the expectations of users, implementations should be capable of running such games at 30fps in full-screen mode. + Implementors should pay attention to the performance characteristics of the `canvas` element which is used for the development of 2D and isometric games. In order to meet the expectations of users, implementations should be capable of running such games at 30fps in full-screen mode. Performance of scrolling, transitions, and animations ----------------------------------------------------- @@ -597,7 +584,7 @@ Acknowledgements ================ - The editors thank Lars Erik Bolstad, Giridhar Mandyam, and Marcos Cáceres for their help collecting use case and requirements. + The editors thank Lars Erik Bolstad and Giridhar Mandyam for their help collecting use case and requirements. The editors thank Matt Kelly for initiating and driving the research on the requirements of top native applications, and also thank WonSuk Lee and Ming Jin and others who contributed to it.