The mission of the Web Applications (WebApps) Working Group, part of the Rich Web Client Activity, is to provide specifications that enable improved client-side application development on the Web, including specifications both for application programming interfaces (APIs) for client-side development and for markup vocabularies for describing and controlling client-side application behavior.
End date | 31 July 2016 Note the group is likely to be rechartered and keep running beyond the end date (to continue specifications not completed at the end of this charter, to work on new versions of completed specifications and to add new specifications). |
---|---|
Confidentiality | Proceedings are Public |
Chairs | Art Barstow Charles McCathieNevile |
Team Contacts (FTE %: 30) |
Yves Lafon Xiaoqian Wu |
Usual Meeting Schedule | Teleconferences: topic-specific calls
may be held up to once per week Face-to-face: we will meet during the W3C's annual Technical Plenary week; other additional F2F meetings may be scheduled (up to 2 per year) IRC: active participants, particularly editors, regularly use the #webapps W3C IRC channel |
As Web browsers and the Web engine components that power them become ubiquitous across a range of operating systems and devices, developers are increasingly using Web technologies to build applications and are relying on Web engines as application runtime environments. Examples of applications now commonly built using Web technologies include reservation systems, online shopping / auction sites, games, multimedia applications, maps, enterprise-specific applications, interactive design applications, and PIM (email, calendar, etc) systems.
The target environments for the Web Applications Working Group's deliverables include browsers on desktop, mobile devices such as phones and tablets, televisions, and other devices, as well as non-browser environments that make use of Web technologies. The group seeks to promote universal access to Web applications across a wide range of devices and among a diversity of users, including users with particular accessibility needs. The APIs must provide generic and consistent interoperability and integration among all target formats, such HTML, XHTML, and SVG.
This charter extends the third Web Applications Working Group Charter to produce deliverables necessary for the evolving Web application market, and continue work already in progress. The group is expected to be rechartered when the charter expires, or earlier if it takes on deliverables beyond the scope of work identified in this charter.
The scope of the Web Applications Working Group covers the technologies related to developing client-side applications on the Web, including both markup vocabularies for describing and controlling client-side application behavior and programming interfaces for client-side development.
Additionally, server-side APIs for support of client-side functionality may be defined as needed.
Web Applications Working Group specifications are expected to be applicable to an array of target formats — including HTML, XHTML, SVG, DAISY, MathML, SMIL, and other DOM-related technology. Although the primary focus will be handling of content deployed over the Web, the deliverables of the Web Applications Working Group should take into consideration uses of Web technologies for other purposes, such as building user interfaces on devices.
The Web Applications Working Group should adopt, refine and when needed, extend, existing practices where possible. The Working Group should also take into account the fact that some deliverables will most likely be tied to widely deployed platforms. It is reasonable for the Working Group to deliver APIs optimized for particular languages, such as ECMAScript. Interfaces for other languages such as Java, Python, C# and Ruby, may be developed in cooperation with the organizations responsible for those languages.
Furthermore, the Web Applications Working Group deliverables must address issues of accessibility, device independence, internationalization, mobility, privacy, and security.
Testing plays an important role in improving the current state of Web applications. Comprehensive test suites will be developed for each specification to ensure interoperability, and the group will assist in the production of interoperability reports. The group will also maintain errata as required for the continued relevance and usefulness of the specifications it produces.
Members of the Web Application Working Group should review other working groups' deliverables that are identified as being relevant to Web Applications Working Group mission.
In order to advance to Proposed Recommendation, each specification is expected to have at least two independent implementations of each feature defined in the specification.
The working group will deliver at least the following:
postMessage
and MessageChannel
.Each specification should contain a section detailing any known security implications for implementers, Web authors, and end users. The WebApps WG will actively seek security, privacy, internationalisation and accessibility review on all its specifications.
After a specification reaches Recommendation status the working group may begin work on, and deliver an updated version of the specification under this charter. Specifications may be moved to Recommendation and a subsequent version begun in order to facilitate the progress of other work which depends on a stable reference.
For a detailed summary of the current list of deliverables, and an up-to-date timeline, see the WebApps WG Publication Status page.
The working group will maintain errata and new editions, as necessary, for the following Recommendation-status specifications:
Some deliverables from the previous charter will no longer be worked on as documented in the group's non-active specs wiki.
The market for applications of Web technologies continues to evolve quickly. Therefore, in addition to the specifications described in this charter, the Web Applications Working Group may take on additional specifications necessary to enable the creation of Web applications to meet the needs of the market as it evolves.
Specifically, because of the close relationship of the WebApps WG and the HTML WG in terms of participants, market, and community, the WebApps WG may opt to take on a limited number of specifications which were initially part of the HTML5 specification that have been split off for more general use with other languages. Consistent with W3C process, an Advisory Committee Review will evaluate whether the additional deliverable should be added to the WebApps WG charter. The expectation is that if the review is successful, Working Group participants will not be required to re-join the Working Group. For any work transferred to the WebApps WG, the first draft published in the WebApps WG is considered the first public Working Draft for application of the Patent Policy exclusion rules.
Other specification proposals may be identified by new submissions from Members, or by market research. These deliverables will require rechartering the Working Group.
For all new deliverables, the WebApps WG should develop an associated requirements section or document that identifies demonstrable use cases.
Other non-normative documents may be created such as:
A comprehensive test suite for all features of a specification is necessary to ensure the specification's robustness, consistency, and implementability, and to promote interoperability between User Agents. Therefore, each specification must have a companion test suite, which should be completed by the end of the Last Call phase, and must be completed, with an implementation report, before transition from Candidate Recommendation to Proposed Recommendation. Additional tests may be added to the test suite at any stage of the Recommendation track, and the maintenance of a implementation report is encouraged.
The group's Specification Status document provides current data about all of the group's specifications, including Technical Report publication plans and testing status. Although group expects to progress all of its specifications during this charter period, the charter does not include detailed milestone data for each specification because such data is speculative and easily becomes out of date. Nevertheless, the following specifications are considered priorities for the group because some other group has a dependency on the specification. For each of these specifications, some milestone predictions are provided, but please see the Specification Status document for accurate data.
A number of specifications depend on the WebIDL specification, which is therefore a very high priority for the Working Group.
Several specifications have a dependency on HTML.
The Web Sockets specification has an effective dependency on the protocol defined by the IETF's HyBi Working Group.
Given the large number of deliverables and therefore also dependencies between this working group and accessibility groups, the WebApps team contact(s) will liaise with the team contact for WAI PF in order to ensure early identification of specifications with potential accessibility aspects, and to ensure coordination as needed during their development.
The specifications of several other groups, such as HTML and SVG, depend upon particular Web Applications Working Group specifications. Where possible, additional dependencies will be avoided to prevent the disruption of dependent deliverables.
The Web Applications Working Group expects to maintain contacts with at least the following groups and Activities within W3C (in alphabetical order):
Furthermore, the Web Applications Working Group expects to follow the following W3C Recommendations, Guidelines and Notes and, if necessary, to liaise with the communities behind the following documents:
The following is a tentative list of external bodies the Working Group should collaborate with:
To be successful, the Web Applications Working Group is expected to have 10 or more active participants for its duration, and to have the participation of industry leaders in fields relevant to the specifications it produces.
For each specification the Working Group will name at least one Test Facilitator whose responsibility is to ensure that a Test Suite is made available.
The Chairs, specification Editors and test Facilitators are expected to contribute one to two days per week towards the Working Group. There is no minimum requirement for other Participants.
The Web Applications Working Group welcomes participation, with agreement from each participant to the provisions of the W3C Patent Policy.
The working mode of the group is described in detail on its wiki. In general the group does not hold teleconferences, and meets face to face at the TP/AC. It may hold more meetings, and certain specifications are developed with regular teleconferences. Note the Decision Policy below with regards to synchronous meetings.
Most of the technical work of the group will be done through discussions on one of the group's public mailing lists. Subscription to these lists is open to the public, subject to W3C norms of behavior.
Editors within the group will use either the W3C's public CVS repository or Mercurial Repository, or Github to maintain Editor's Draft of specifications. The group's action and issue tracking data will also be public, as will the Member-approved minutes from all teleconferences.
The group uses a Member-confidential mailing list (member-webapps) for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a particular member requests such a discussion. There is also a Team-confidential mailing list for coordination between the Team and Chairs.
Up-to-date information about the group (for example, details about deliverables, issues, actions, status, participants) is available from the Web Applications Working Group home page.
As explained in the W3C Process Document (section 3.3), this group will seek to make decisions when there is consensus and with due process. The expectation is that typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required. However, if a decision is necessary for timely progress, but consensus is not achieved after careful consideration of the range of views presented, the Chairs should put a question out for voting within the group (allowing for remote asynchronous participation -- using, for example, email and/or web-based survey techniques) and record a decision, along with any objections. The matter should then be considered resolved unless and until new information becomes available.
Any resolution taken in a face-to-face meeting or teleconference is to be considered provisional until 10 working days after the publication of the resolution in draft minutes sent to the working groups mailing list. If no objections are raised on the mailing list within that time, the resolution will be considered to have consensus as a resolution of the Working Group.
This charter is written in accordance with Section 3.4, Votes of the W3C Process Document and includes no voting procedures beyond what the Process Document requires.
This Working Group operates under the W3C Patent Policy (5 February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis.
For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation.
This charter for the Web Applications Working Group has been created according to section 6.2 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.
This section is informative
The following is a brief summary of the important changes to the charter.
Copyright© 2014 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved.
Date: 2014-June-03