ISSUE-94 (webcoresplit): Split Web Application Core and UA specific elements into separate spec [HTML 5 spec]

ISSUE-94 (webcoresplit): Split Web Application Core and UA specific elements into separate spec [HTML 5 spec]

http://www.w3.org/html/wg/tracker/issues/94

Raised by: Shelley Powers
On product: HTML 5 spec

Currently the HTML5 specification contains a section, Section 5, devoted
primarily to user agents like browsers. The section notes that though it is focused on browsers, requirements in the section apply to all user agents, not just browsers, unless otherwise noted.

Though browsers are a major user agent for HTML/XHTML, they are not the only
user agents. In particular, ebook technology is dependent on XHTML, and forms a
completely different class of user agents than browsers. In addition, there are
email applications that exist outside of browsers that also make use of
HTML/XHTML, in addition to some word processing software.

Though the section does provide a good reverse engineering of browser
technology, most of the section has little to do with HTML, in general. In
addition, it also has little to do with the Document Object Model (DOM), which is based on the HTML syntax, not objects implemented by various browsers. 

Including this section greatly extends the HTML5 specification beyond the
charter, and beyond boundaries one can reasonably expect from an effort focused
on HTML, both the XML serialization and non-XML serialization, and the DOM. In
addition, by focusing the specification primarily towards browsers, we are
limiting the usefulness of the HTML specification for other uses, both now, and
in the future. Though one could say that the use of XHTML by eBooks is incidental to the development of a web-based language, that the ePub standard evolved from XHTML is a demonstration of the quality of a well-defined spec: new uses can evolve. 

Encapsulating everything relevant to browsers in the HTML spec is counter to good, technology practices. Consider how a programmer creates an application. They look for opportunities to create reusable objects, which they then use to create any number of applications, not just one. We should follow the same philosophy when creating a new version of HTML: restrict our effort to a new version of HTML, its serialization in XML, and the DOM. This will include new elements, such as video, which may not be useful for all variations of user agents, but the concept behind the new elements still fits within our perceptions of what we would reasonably expect from an HTML specification. 

Simplifying the HTML5 specification in this way will greatly increase its
usability by many user agents, not just browsers. A standardized UA or Browser Object Model, or Web Applications Core can reference the HTML, true, but so can other specifications, such as ePub (for eBooks) and so on.

In addition, browser technology expands at a faster pace than that for the
underlying HTML specification. By separating Section 5 out, the work can then be
incorporated into a new effort that can be focused specifically on the class of
user agents, which includes browser. This new effort won't then be dependent on the same release cycle as HTML. 

Separating the section out isn't necessarily of ripping the section out without checking cross-references. Care would need to be taken to ensure best effort, and there should be an additional effort to ensure a group is ready to absorb the newly separated out material and move it forward to FPWD and beyond.

Another advantage to separating the material out is the fact that the work could be accessible by other specifications, and not just HTML. For instance, most of the effort would also be application to SVG, as well as HTML/XHTML. 

Additionally, separating the material out should prevent confusion about the location of the material in the future. The browser object model, as it has been informally termed, has been around almost as long as HTML, but has existed separate from HTML. To suddenly combine the two will cause confusion about where to find the pertinent information about the specification. 

Lastly, splitting this section out helps to correct some of the problems with the existing HTML spec, which frequently mixes up the audience in the writing. One sentence is directed at implementor, the next at authoring tools, the third at web page authors, the fourth at web developers--this type of haphazard mixing of audiences will, again, make the specification extremely difficult to follow, and confusing.

Received on Saturday, 9 January 2010 15:42:45 UTC