- Toby Inkster
- html; w3c
On the 10th of June 1215, the a group of English barons invaded London and five days later forced King John to attach his seal to the Magna Carta in Runnymede, on the border of modern-day Sussex and Berkshire. (In those days it was customary to attach ones seal to an agreement rather than sign it. However the fact that it was not signed has led to a popular misconception that King John was illiterate, when in fact he was not.)
The Magna Carta was a key document in English constitutional law, establishing certain rights (such as habeas corpus) for the King's subjects, and limiting the rights of the King; importantly, requiring the King to obey "the law of the land". The Magna Carta is widely regarded as a major influence on world constitutional law, and in particular greatly influenced the United States constitution and Bill of Rights. Three clauses of the Magna Carta remain in force in English law today:
- the freedom of the Church of England;
- the "ancient liberties" of the City of London; and
- the right to due process.
Although the other clauses have been repealed, they have strongly influenced the Acts of Parliament that replaced them.
(It having been signed under duress, Pope Innocent III gave his blessing for King John to renounce the Magna Carta. King John's successor, Henry III, reaffirmed it.)
Fast-forward nearly 800 years, and we see that Apple, Mozilla and Opera, key members of WHATWG are pressuring the W3C to bless HTML5 as the successor to current versions of (X)HTML. I've been watching the development of the W3C's XHTML 2.0 and WHATWG's alternative markup format for several years, and thought I'd share my thoughts on them.
When the W3C commenced work on this standard, it decided that it would allow itself to significantly backwards compatibility in a way that previous (X)HTML standards hadn't. In a way, this was needed. There are many aspects of the current standards that are regarded by many as flawed. Examples include:
- too much use of empty elements such as
<br>to specify divisions in content;
- remaining legacy presentational elements, such as
- lack of a method to specify metadata which applies to part of a document as against the whole document.
Early drafts included several big wins.
<q> element in earlier versions of (X)HTML was a source of frustration to many authors. Although the standards said that authors should not include quote marks around the quoted portions of text, and that user-agents should add them automatically, in a manner fitting with the surrounding text's locale, in practice, many agents did not insert quote marks, and when they did, often inserted the wrong type. To make matters worse, many user-agents also lacked support for the parts of CSS that effect quoting.
Using a complicated system of hacks, it was possible to use
<q> in a manner that worked in most browsers, but due to the difficulty, most authors did not use it.
The new draft swept these problems aside, by replacing the element and specifying that user agents must not automatically quote its contents, and that it was the responsibility of authors to do so, either directly, or via stylesheets. This would enable the
<quote> element to be handled correctly by an XML+stylesheets user-agent without even having to know anything in particular about XHTML.
This was easily predicted. Although neither of these elements was formally deprecated in previous specifications, they were widely considered to be throw-backs to HTML's distant past, having no place in a fully-semantic markup language.
On the W3C's HTML mailing list, numerous edge cases were proposed where they (and
<i> in particular) could be considered justified. Ships' names, words written in foreign languages and Linnean taxonomy terms. However, at least in my own opinion, these are not valid arguments to keep
<i>, but rather arguments in favour of elements to mark up Linnean taxonomy, &c.
Early drafts of XHTML 2.0 removed these elements, along with
An Improved Mechanism for Markup up Line Breaks
<br> element was replaced with an
<l> element. While
<br> is an empty element sitting between two lines of text,
<l> instead surrounds a line. Compare:
<p class="poem"> I think that I shall never see<br> A poem as lovely as a tree. </p> <p class="poem"> <l>I think that I shall never see</l> <l>A poem as lovely as a tree.</l> </p>
There is something wonderfully symmetrical about the proposed new method.
A Whole New Paradigm for Headings
In one of the more radical changes, a new paradigm was introduced for headings. What would in HTML 4 have been:
<h1>Main Heading</h1> <p>Foo.</p> <h2>Subheading</h2> <p>Bar.</p> <h3>Third Level Heading</h3> <p>Baz.</p> <h2>Another Subheading</h2> <p>Quux.</p>
became the following under the new system:
<section> <h>Main Heading</h> <p>Foo.</p> <section> <h>Subheading</h> <p>Bar.</p> <section> <h>Third Level Heading</h> <p>Baz.</p> </section> </section> <section> <h>Another Subheading</h> <p>Quux.</p> </section> </section>
<h>Main Heading</h> <section> <p>Foo.</p> <h>Subheading</h> <section> <p>Bar.</p> <h>Third Level Heading</h> <section> <p>Baz.</p> </section> </section> <h>Another Subheading</h> <section> <p>Quux.</p> </section> </section>
The W3C was never really clear on whether a heading should be inside its section or outside. Consistancy with
<fieldset> would lead one to assume that it should be inside, but the examples given in the drafts seemed to suggest that the reverse might be the case.
Either behaviour has advantages over the older system:
- Allows more than six levels of heading; and
- Makes it easier to transclude a document or section of a document into another file without having to manually adjust heading levels.
However, for "backwards compatibility" (despite the fact that XHTML 2 isn't supposed to be backwards compatible), the
<h6> elements are kept. Their exact relation to
<h> is never explained.
<nl> <label>Contents</label> <li href="#introduction">Introduction</li> <li> <nl> <label>Terms</label> <li href="#may">May</li> <li href="#must">Must</li> <li href="#should">Should</li> </nl> </li> <li href="#conformance">Conformance</li> <li href="#references">References</li> ... </nl>
Notice in the above example, that the
href attribute is applied directly to the
<li> element, and no
<a> element is needed. That's because...
Everything's a Link!
Well, not everything. Your mouse wouldn't have a place to rest. But virtually every element is allowed to take an
href attribute and become linkified.
<a> still exists, but there's nothing special about it anymore.
href inevitably comes
type to specify what sort of thing is at the other end of the link. (Is it a JPEG image? An MP3 audio file?)
And that's not all...
Everything's an Image... err... Object.
Having distributed the special powers of the
<a> element, in the next draft, the W3C did the same to
<object>. Suddenly every element could take a
src attribute and become an embedded image or file.
<p src="holiday.png" type="image/png"> We had a wonderful time on holiday. </p>
User-agents that supported embedded PNG images would show the picture instead of the text. Other agents would gracefully fall back to displaying the content of the paragraph.
This left the issue where an element could be both a link and an embedded image. In which case, did the
type attribute refer to the MIME type of the linked file or the embeded one? Both?
The last change I'll mention is the change to metadata which removed the
content attribute in favour of putting content inside the element itself
HTML 4: <meta name="author" content="Toby Inkster"> XHTML 1: <meta name="author" content="Toby Inkster"/> XHTML 2: <meta name="author">Toby Inkster</meta>
The drafts did also remove the
scheme attribute. I have no idea why.
In later drafts, the
<meta> element was allowed to break free of the
<head> element and be placed inside any other part of the document, providing element-level metadata. This would allow you to specify, say, that a particular section of a document had a different author.
It was after this work though, that the W3C HTML Working Group lost the plot.
Supplanting Semantics and Functionality into Attributes
In HTML 4, you can tell what sort of thing an element represents by looking at what the element name is. If the element is
<p>, it's a paragraph; if it's
<strong> then it's some very important text.
In later drafts of XHTML 2, more and more of these kind of functions were moved into attributes. The examples above of
<a> having their special meanings removed were just the tip of the iceburg.
Recent drafts have introduced a
role attribute, the function of which seems to be as a generic container for any future semantics.
Rather than introducing a
<navigation> element or such, for the large blocks of navigation menus and search forms typically found on web pages, we were given a value for
role. So instead of a neat construct like:
<main> <h>About Foo, Bar & Baz</h> <p>...</p> </main> <navigation> <p> If you liked this, you may like… <nl> <label>Other articles</label> <li href="/qq">Quux & Quuux</li> <li href="/xyzzy">The Story of Xyzzy</li> <li href="/abg">Arfle, Barfle & Gloop</li> </nl> </p> </navigation>
<div role="main"> <h>About Foo, Bar & Baz</h> <p>...</p> </div> <div role="navigation"> <p> If you liked this, you may like… <nl> <label>Other articles</label> <li href="/qq">Quux & Quuux</li> <li href="/xyzzy">The Story of Xyzzy</li> <li href="/abg">Arfle, Barfle & Gloop</li> </nl> </p> </div>
role attribute here seems to offer precious little advantage over the existing
class attribute. The draft defines a number of pre-specified values for the attribute and recommends that authors use namespaces when defining others. Similar suggestions had originally been made for that
rev attributes in HTML 4, but that never really worked out. How many sites formally define metadata profiles? It's quite clear that
role would quickly become a second
class attribute, just a little bit more difficult to apply CSS to.
The Metadata Platform
Later drafts of XHTML 2 introduced the
about attribute and the concept of metadata chaining, thereby transforing XHTML's metadata capabilities from a simple set of tools for providing very basic data regarding a web page to a full metadata platform comparable with RDF.
about attribute allows me to specify to which item a particular piece of metadat refers. An example from the draft is:
<html xmlns:dc="http://purl.org/dc/elements/1.1/"> <head> <link about="#q1" rel="dc:source" href="urn:isbn:0140449132" /> </head> <body> <blockquote id="q1"> <p> 'Rodion Romanovitch! My dear friend! If you go on in this way you will go mad, I am positive! Drink, pray, if only a few drops!' </p> </blockquote> </body> </html>
Neat, yes, but not really needed, as the following syntax was already OK:
<html xmlns:dc="http://purl.org/dc/elements/1.1/"> <head> </head> <body> <blockquote> <meta property="dc:source">urn:isbn:0140449132</meta> <p> 'Rodion Romanovitch! My dear friend! If you go on in this way you will go mad, I am positive! Drink, pray, if only a few drops!' </p> </blockquote> </body> </html>
(Oh yes, it's worth noting that they changed the
name attribute to
However, you'll note that the
about attribute takes as its value a URL. This allows me to specify metadata about anything that has a URL! For example:
<meta about="http://www.yahoo.com" property="dc:title">Yahoo!</meta> <meta about="http://www.google.co.uk" property="dc:title">Google</meta>
Frankly, I don't see what business I have specifying metadata about somebody else's web site. I don't see why the markup language should give me that ability.
Example from the most recent draft:
<head xmlns:dc="http://purl.org/dc/elements/1.1/"> <link rel="dc:copyright" href="http://example.com/company/BBC/6"> <meta property="dc:location">London</meta> </link> </head>
This metadata states that the article is copyright by the BBC, and that the BBC is based in London. (Note for the W3C: it's moving to Manchester soon.) Again, I'm specifying data about the BBC, and what business do I have doing that?
(As an aside: does it really say that the BBC is based in London, or that the particular web page http://example.com/company/BBC/6 is hosted in London? How can you tell?)
Metadata within Content
The same information (e.g. authorship, modified date, title, etc) is often duplicated within a document: it's in the metadata and in the body. Recent XHTML 2 drafts seek to reduce this duplication:
<html xmlns="http://www.w3.org/2002/06/xhtml2/" xmlns:dc="http://purl.org/dc/elements/1.1/"> <head> <title>... title ...</title> </head> <body> ... <span property="dc:date" class="date"> 2004-03-23 </span> <span property="dc:title" class="headline"> High-tech rollers hit casino for £1.3m </span> By <span property="dc:creator" class="byline">Steve Bird</span> <span class="standfirst"> Word of a hand-held device which can beat the roulette wheel has gambling bosses quaking </span> ... <p>...</p> </body> </html>
Seems nice, but... errr... isn't this just the
role attribute again with a different name?
XHTML 2 and its Relationship to RDF
The latest XHTML 2 draft has information on a one-to-one mapping between XHTML 2 and RDF. This alone should be enough to trigger alarm bells, as RDF is the great, big, hundred tonne juggernaut of metadata.
HTML was initially popular because it was a "small" markup language that allowed authors to markup documents quickly and easily, with elements that were useful on the Web (e.g. elements that did text, linking and embedding). (HTML 3.2 has 70 elements, and HTML 4.01 had 77; compare this with the current XHTML 2 draft which has 89.)
XHTML 2 not only provides a larger set of elements, but the elements themselves are less important -- it is the combination of element and attribute that provides functionality. And the number of possible combinations is huge.
This, together with an RDF-like metadata platform and the effort of defining and managing namespaces combine to make XHTML 2 a far more complex markup language to write, and to infer meaning from.
It just doesn't seem "HTML-ish" anymore.
In 2004, after a W3C workshop, Apple, Mozilla and Opera were becoming increasingly concerned about the W3C's direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out to with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.
WHATWG have approached development rather differently from the W3C. Rather than starting with XHTML 1.1 as a base for work, they've taken HTML 4.01,
<font> tag and all! Whatsmore, they've opted to preserve backwards-compatibility as much as possible. Because of this, it's been rather diffcult for them to introduce new ways of doing things, because the old ways need to be preserved too.
Like XHTML 2, HTML5 introduces a
<section> element for marking up a section of a document. It also introduces several other elements for marking up particular types of section. These elements would in XHTML 2 be marked up using the
role attribute on a normal
However, somewhat bizarrely, XHTML 2's
<h> element is not introduced. I assume that this is because of WHATWG's backwards compatibility decision (see above).
This means that authors instead must use
<h6> elements to mark up headings. However, the standard specifies that all heading elements are considered semantically equivalent, and that heading level should be entirely inferred from its level of nesting with sections. That is, the following two examples are semantically equivalent:
<body> <h4>Apples</h4> <p>Apples are fruit.</p> <section> <h2>Taste</h2> <p>They taste lovely.</p> <h6>Sweet</h6> <p>Red apples are sweeter than green ones.</p> <h1>Color</h1> <p>Apples come in various colors.</p> </section> </body>
<body> <h1>Apples</h1> <p>Apples are fruit.</p> <section> <h2>Taste</h2> <p>They taste lovely.</p> <section> <h3>Sweet</h3> <p>Red apples are sweeter than green ones.</p> </section> </section> <section> <h2>Color</h2> <p>Apples come in various colors.</p> </section> </body>
HTML5 introduces a number of brand new elements, particularly ones that would be useful for web applications, such as progress metres. Here's an example:
<meter value="0.25">Low activity</meter>
Others include methods for marking up time, highlighted text and so on. Many of these will see immediate use when browsers support them.
Many content authors have wished for a method of applying a stylesheet to just a particular part of a web page. HTML5 allows this via the
scoped attribute on the
Perhaps a little nicer would be to use the
for attribute, which the
<th> elements already have?
The HTML5 draft contains a number of predefined values for the
class attribute. In effect, this is a bit like XHTML 2's
property attribute. Compare:
XHTML 2: <p xmlns:dc="http://purl.org/dc/elements/1.1/" property="dc:copyright">© 2007 Toby Inkster</p> HTML5: <p class="copyright">© 2007 Toby Inkster</p>
The draft specifies a mechanism for the community to propose new predefined classes too. The HTML5 mechanism for predefined classes certainly seems a lot easier and cleaner than the XHTML 2 method, but it does have its disadvantages too:
- Dublin Core is cool. XHTML 2 provides a santioned method for me to use DCMI metadata in my documents; HTML5 does not.
- It's not really backwards-compatible. As the
classattribute is virtually free-form text in current versions of HTML, people may be already using the
copyrightclass, and other HTML5 predefined classes, for purposes other than those that WHATWG proposes.
Extended Form Functionality
These include fancy date pickers, WYSIWYG rich text editors and e-mail and url input elements. Some client-side validation can be conducted without scripting, such as minimum and maximum values for inputs, marking inputs as "required" and providing regular expressions to validate input.
A full write-up of these new capabilities is beyond the scope of this document, please read the current Web Forms 2.0 working draft if you wish to find out more.
Server-sent events are cool. Opera 9 supports them. They will probably prove to be a successor/complementary technology to AJAX.
However, not everything in the WHATWG specification is rosy either. It is lacking in some areas.
Lack of DOCTYPE
The first line of an HTML5 document must be:
The lack of a full DOCTYPE with a URL would make SGML validation of the document impossible, and would make it impossible for a user agent to guess what version of HTML the document is written in. This is a step towards a world of tag soup.
DOM Extensions in HTML Standard
As well as proposing a new version of HTML, HTML5 also proposes extensions to the DOM . Although a new version of HTML probably does need a new version of the DOM to go along with it, this should probably be kept separate.
Previous HTML standards have been very clear on the fact that HTML is a data format. Once a user-agent has parsed the data, it is the agent's choice what to do with it; how to present it.
The HTML5 standard specifies, in some cases very exactly, how user agents should behave. This reduces the ability of browser makers to introduce innovative new presentation techniques, so I'm surprised that a specification primarily shaped by three browser manufacturers would do this.
Blessing Current Broken Markup
In a number of places, the HTML5 specification gives its blessing to a variety of current practices which many would describe as broken. For example, '/>' endings on empty elements are allowed in HTML5.
This is for "backwards-compatibility" purposes, but note that it is not backwards compatible with earlier standards, but is rather backwards compatible with existing error-recovery routines in browsers.
As justification, HTML5 cites "security", stating that if different software uses different mechanisms to determine content type, then a file that might be considered an image by one program might be seen as an executable by another, which would attempt to run it.
Firstly... if only there was an agreed method by which browsers could determine the content type of a resource consistently. Oh yes... there is -- the HTTP Content-Type header.
Secondly, what in the name of all that is good, is a browser doing running things it just downloaded of the Internet willy-nilly?!
Netscape 4.x had this
<embed> tag for embedding objects. Some people for some reason still use it, despite the fact that modern browsers have supported the standards-compliant
<object> element for longer than I care to remember.
HTML5 blesses the
<embed> element, despite the fact that it does exactly the same thing that
<object> already does.
Again, HTML5 is more complex than the standard that precedes it. In the current draft, HTML5 contains 100 different element, compared to 77 in HTML 4.01 Strict.
Much like King John in the 13th century, the W3C had somewhat lost the plot when it comes to how real people wanted XHTML to develop. Early drafts looked promising, but as work progressed, the draft recommendation started to look distinctly un-HTML-like. Mozilla, Opera and Apple can be seen as the rebellious barons, and late last year, seemingly under duress, Sir Tim announced the revival of the W3C HTML Working Group (as distinct from the XHTML Working Group).
The question remains over how much of WHATWG's drafts the new working group will use in the next W3C recommendation; and how much work (if any) will be carried over from XHTML 2.
The Tao of HTML 5
"Tao" roughly translates as "the way" or "the path". Here's the path I'd choose...
Start with HTML 4.01 Strict
Can we all at least agree that we don't want to bring
<font> et al kicking and screaming into the 21st century?
Give us these useful new section elements from WHATWG's draft. They help codify personal conventions. (Most authors have particular IDs that we assign to
<div> elements to mark up this type of content -- this will help make document markup moe consistent.)
WHATWG defines these elements too. Give us these as well, but make their content model the same as
<section> for simplicity's sake.
And give us
<h> from XHTML 2. It makes for more logical headings.
<h6> for backwards compatibility purposes, but deprecate them. They should use WHATWG's semantics.
Allow classes to contain a colon. Specify that when a class contains a colon, it should be treated as a semantic class belonging to a particular namespace. This gives us a mechanism that combines HTML5's predefined classes and XHTML 2's
<div class="smallprint"> This document was last modified on <span class="dc:date.modified">2007-04-15</span>. </div>
Use WHATWG's Web Forms 2.0. You know it makes sense.
Other elements peripherally related to forms that should be taken from HTML 5 include:
Similar to the difference between the Strict and Loose types of HTML, a non-form flavour of HTML 5 could be created, without any of the above listed elements, nor
Deprecate, Deprecate, Deprecate!
In with the new, means out with the old. And that includes:
Deprecated elements should be allowed but discouraged. Validators should output a warning when they encounter them, but not an error. Which brings me to...
HTML 5 documents must have a method of identifying themselves as such. That could be through a particular DOCTYPE tag, a
version attribute to the
<html> element, a namespace, or something new altogether. But there has to be a reliable way of identifying an HTML 5 document. This will help those who draw up standards for HTML 5.1.
We need validation of some kind. Again, I'm not asking for SGML-style validation necessarily, but if you take away our functioning DOCTYPE, you need to provide us with some other method to validate our pages.
Extend the existing
for attribute to apply to the
<meta> elements to supply styling information and metadata for particular parts of a document.
XHTML 2-style navigation lists would be welcome.
I'm a little undecided on this one. With
<samp>, I think HTML already has too many computer science related elements. But
<blockcode> is nice.
The Opposite of
We need an opposite of
<em> for marking up text that should be de-emphasised. Some have suggested retasking
<small> for this purpose.
Do we really need
<strong>? How about this:
<p>Here is some <em><em>very important</em></em> text.</p>
Introduce XHTML 2's
<br> should be deprecated.
Style of Standard Document
The WHATWG document contains too much implementation-specific information, such as algorithms. While I think that it's important for browser developers to work together to achieve interoperable implementations, this sort of information does not belong in the HTML 5 standard. It should be on as a separate complementary project.
The HTML 5 recommendation should be written as plain language as possible without being ambiguous or overly verbose, in order that it may be easily understood by HTML authors, as HTML authors are likely to make up the vast majority of the audience for the recommendation.
Plenty of examples should be included, along with examples of renderings in a variety of different rendering engines, no more than half of which should be "traditional" desktop browsers -- HTML authors need to be made aware that their markup will be interpreted by a variety of different devices.
Hopefully such an approach would provide a good structured, semantic markup language that can shrug off its presentational past, yet still "feels like HTML". It should provide additional form capabilities for web application developers, and help provide a richer desktop-like experience for web applications.
Remember that despite how the Magna Carta was obtained, it went on to become a key document that has shaped constitutional law worldwide and has protected the rights of British citizens for over three quarters of a millenium.