Zero-edit Change Proposal for ISSUE-41

Summary

The basic question of ISSUE-41 is (as asked on public-html) "should HTML 5 provide an explicit means for others to define custom elements and attributes within HTML markup?" In a word, no. HTML5's existing extension points provide all the features needed to solve the use cases that give rise in some to the desire for DE. "There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the 'bad old days' without working with interested parties to make sure their feature is well designed." (from the WHATWG FAQ).

Rationale

I've gathered together many of the use cases for DE I could find posted to public-html, each attributed to the original email, blog post, or such which defined it. I've also tried to consolidate similar or identical use cases together so as to avoid redundancy.

All but one of these use cases can be addressed with the existing HTML extension points. The remaining use case is best left unaddressed, as discussed later on in this CP.

HTML's exisiting extension points

HTML has many existing extension points for authors to use.

As listed in section 2.2.2 Extensibility:

• Authors can use the class attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.
• Authors can include data for inline client-side scripts or server-side site-wide scripts to process using the data-*="" attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.
• Authors can use the <meta name="" content=""> mechanism to include page-wide metadata by registering extensions to the predefined set of metadata names.
• Authors can use the rel="" mechanism to annotate links with specific meanings by registering extensions to the predefined set of link types. This is also used by Microformats.
• Authors can embed raw data using the <script type=""> mechanism with a custom type, for further handling by an inline or server-side scripts.
• Authors can create plugins and invoke them using the <embed> element. This is how Flash works.
• Authors can extend APIs using the JavaScript prototyping mechanism. This is widely used by script libraries, for instance.
• Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.

Additionally, authors may use appropriate elements and attributes from other applicable specifications, such as HTML5+RDFa, to imbue their documents with specialized semantics.

Vendors unwilling to add additional extension points at this time

Representatives of browser vendors have expressed reluctance to add additional extension points to HTML, including Microsoft, who think DE "isn't important enough to justify changes [to the spec] at this time" (source).

Use Case 1

Annotate structured data that HTML has no semantics for, and which nobody has annotated before, and may never again, for private use or use in a small self-contained community. (source)

Structured data can be published in HTML by using class="" and rel="" as in Microformats, with the Microdata feature, with HTML5+RDFa, or several of the other existing extension points, both separately and together.

Use Case 2

Site owners want a way to provide enhanced search results to the engines, so that an entry in the search results page is more than just a bare link and snippet of text, and provides additional resources for users straight on the search page without them having to click into the page and discover those resources themselves. (source)

A search engine could define a Microdata or RDF vocabulary for publishers to use.

Use Case 3

Remove the need for feeds to restate the content of HTML pages (i.e. replace Atom with HTML). (source)

The hAtom microformat solves this use case, and it is built on top of the existing extension points of HTML.

Use Case 4

Remove the need for RDF users to restate information in online encyclopedias (i.e. replace DBpedia). (source)

The HTML5+RDFa spec being worked on by this WG can address this use case, as can the Microdata feature.

Use Case 5

There will always be a need for people to unilaterally extend the language to address problems we are currently unaware of and that therefore are not covered by existing functionality; without trampling on the toes of others; and without being beholden to an external entity to provide the enhancements for the author on a timescale that is useful to the author. (source 1, source 2)

As with use case 1, such extensions can be published in HTML by using class="" and rel="" as in Microformats, with the Microdata feature, with HTML5+RDFa, or several of the other existing extension points, both separately and together. Name collisions can be avoided in several different ways, and authors do not need to wait for browser vendors to implement anything new before they can start using their extension.

Use Case 6

Round-trip metadata across sessions, maintaining a strong metadata association that is resilient to subsequent editing operations by other user agents. Both whole HTML files and smaller document fragments need to round-trip. Such metadata may include information about a WYSIWYG editor's state, author information, relationships between this document and others, or a reference to the document's original source. (source)

This use case can be addressed with the existing extension points of HTML:

• Editor state informaiton can be placed in data-*="" attributes.

• Author information can be represented by <meta name=author>; author is one of the standard metadata names.

• Relationships between this document and others can be expressed using the rel="" attribute.

• References to the document's original source can be expressed using rel=alternate or rel=bookmark, both standard link relations, or a custom link relation could be used.

Use Case 7

An existing software product currently outputs XHTML documents with other, non-SVG and non-MathML Namespaces-in-XML content mixed in. Users of this product would like to publish such content as text/html, and to have content published as such pass HTML5 conformance testing.

This use case cannot be addressed by use of HTML's existing extension points. This is a feature, not a bug. As stated in section 2.2.2 Extensibility: "Vendor-specific proprietary user agent extensions to this specification are strongly discouraged. Documents must not use such extensions, as doing so reduces interoperability and fragments the user base, allowing only users of specific user agents to access the content in question." Of course, such software can continue to use XHTML.

One of the other DE Change Proposals describes three classes of such extensions.

Platform Extensions

"Platform Extensions" such as SVG and MathML that define new types of content that can be rendered in a browser. These extensions are expected to be vendor-neutral and have a specification. They may become part of HTML in the future.

Such extensions should be coordinated among browser vendors within this working group.

Language Extensions

"Language Extensions" such as RDFa that define new attributes on top of nodes from other namespaces.

As argued on public-html, "it's good to allow other standards to define new HTML elements and attributes (not necessarily W3C standards, but using some form of open standards process), and have the resulting markup still validate. The standards process itself can prevent namespace conflicts in this case. HTML5 already allows for this though..."

Vendor-specific Experimental Extensions

"Vendor-specific Experimental Extensions" such as the experimental features that Webkit and Mozilla have created.

The spec already provides for this with the vendor--feature="" pattern for vendor-specific attributes. Just as with -vendor-foo CSS properties, use of such attributes should not be considered conforming.

Not providing such a feature for element names is intentional; for an excellent argument against such a feature, see this email to public-html.

Details

No change to the spec.

Impact

Positive Effects

We avoid adding complex new features without concrete use-cases to the already complex web platform.

Negative Effects

If a particular use-case isn't addressed, users may end up attempting to extend HTML themselves in a non-conformant manner. This has been a potential problem for decades in HTML, however, and we haven't seen very much actual damage. As well, the majority of extensibility use-cases have already been addressed in HTML, so that further limits such potential damage.

Conformance Classes Changes

No change.

Risks

None. After all, we can always add further extension mechanisms later should the need arise.

References

References are linked inline.

Contributors

• Initial draft of this Change Proposal by Ian Hickson
• Edward O'Connor
• Tab Atkins

Other collaborators welcome!