This charter is obsolete. It was written in 2004 and no longer represents how the WHATWG operates. For a more up to date description read Working Mode, FAQ, and Policies. The text below remains solely for the historical record.
Software developers are increasingly using the Web to deploy their applications. User Agents serve as front ends for server-based applications, and W3C technologies — including HTML, CSS and DOM — are often used to build user interfaces to these applications. Along with ECMAScript, these technologies provide a foundation for Web applications.
However, the aforementioned technologies were not developed with Web applications in mind, and Web applications often rely on unintended features not fully described by the specifications. The next generation of Web applications will add new requirements to the development environment — requirements these technologies are not prepared to fulfill alone. New technologies being developed by the W3C and IETF can contribute to Web applications, but these are often designed to address other needs and only consider Web Applications in a peripheral way.
The goal of the Web Hypertext Applications Technology Working Group is to address the need for one coherent development environment for Web applications, through the creation of technical specifications that are intended to be implemented in mass-market Web browsers.
The expected deliverables include:
Other deliverables may be found to be needed to cover other areas that Web application developers require. For instance we may work on specifications for new semantic elements that cover common scenarios such as those found in e-commerce, forums, Web logs, and games. The list of deliverables above is not meant to be exclusive.
All specifications produced by this working group must take into account backwards compatibility, and clearly specify reasonable transition strategies for authors. They must also specify error handling behaviour to ensure interoperability even in the face of documents that do not comply with the letter of the specification.
Working group contributors will contribute to this activity through a publicly-archived and open-subscription mailing list. The working group members should also respond to queries from the public on this mailing list.
Each document shall have an assigned editor. Editors should reflect the consensus opinion of the working group when writing their specifications, but it is the document editor's responsibility to break deadlocks when the working group cannot come to an agreement on an issue.
Specifications will be developed in public, with the latest version always publically available. During development, the working group may decide that a document has reached a stable stage and is in need of wider review. At this point the document will be archived in its current state, and a call-for-comments will be announced. Drafts in this stage should bear a warning informing readers that the specification is not considered ready for non-experimental implementations, and that experimental implementations of the draft must not be included in end-user products.
The working group can make a decision to publish a stable version of a document only if the overwhelming majority of the working group members agree that the document is ready.
When a draft has been subjected to a call-for-comments in which no new and useful comments have been received, the working group may decide that the specification is ready to be implemented in Web browsers (both for desktop and low-end devices) and shipped to end users. At this stage, the document will be archived, and a call-for-implementations will be announced.
In order for a draft to proceed past the call-for-implementations stage to the recommendation stage, there must be at least two interoperable implementations for every feature. For the purposes of this criterion, we define the following terms:
If implementation feedback warrants it, or if implementations are not found to be sufficiently interoperable, specifications in the call-for-implementations stage will be returned to the draft stage to address the issues raised and reasons for implementation differences.
Anyone can contribute by subscribing to the mailing list. The list of subscribers to the mailing list are termed the contributors.
Membership is by invitation only, and consists of a number of representatives from various browser manufacturers. This group, which is referred to as the members, will provide overall guidance as described in the charter above. The members currently consists of: