2004-07-12 12:24 UTC Extending HTML
So Apple decided to make up some new tags.
To be precise, they invented a new element, a new attribute, and a
new value. The new element is canvas, an element that
does nothing except provide a DOM interface for graphics drawing; the
new attribute is composite, a presentational attribute
that can be applied to images; and the new value is
search on the type attribute of
input elements, which provides a control for incremental
search interfaces.
These new tags are to be used in several places. One of these is Dashboard, where applications written in an HTML-like interpreted language are executed in a runtime environment similar to a Web browser's. Another place where these tags are to be used, I am told, is the real Web.
The response to this announcement from a number of people in the industry seemed to be outrage... about the syntax.
Hello?
Here is Apple introducing their own proprietary markup to the Web, without going through any sort of standardisation first (not even unofficial standardisation like the WHATWG), and what people complain about is the syntax?
For instance, Eric Meyer (great guy) says:
I hope that what Dave is really saying is that Dashboard widgets are actually XML, albeit an XML that looks very much like HTML except they've added some nifty stuff to it. If so, great, fine, no problem. XML lets you do whatever you want, really.
So let me get this right. It's ok to send proprietary non-standard markup over the Web, so long as the angle brackets are XML angle brackets and not HTML angle brackets?
This makes no sense. Proprietary markup is proprietary markup, whether it is HTML-based, XML-based, or any other language such as PDF, Microsoft Word, XAML, or Flash. It's not the exact order of the angle brackets that matters, it's the lack of open, consensus-driven specifications, the lack of interoperability.
Eric wasn't the only person arguing that Safari's extensions are abominable because they can be used as if they were HTML elements, I just picked on him because I know he won't take it personally!
There have been several "solutions" proposed to the "problem" of proprietary tags being added to HTML.
The first is using namespaces in HTML. There is one fundamental problem with that idea. HTML doesn't have namespaces. At all. HTML doesn't allow namespaces. The Namespaces-in-XML spec doesn't apply to HTML. However you cut it, there simply isn't a way to allow namespaces in HTML. If you were to add namespaces to HTML, all you would be doing is adding yet another non-ratified extension on top of the original extension.
The second proposed solution is to use namespaces in XHTML,
sending it as text/html. This also can't be done, this time
because while you can use namespaces in XHTML (with some caveats; see
below), you can't send such XHTML as text/html. The only
things you can send as text/html (according to the relevant RFC) are HTML
documents (up to version 4.01), and XHTML1 documents complying to the
compatibility
profile. (Although I would strongly recommend
against doing that anyway.)
The third proposed solution is to use namespaces in XHTML, sending it using a legitimate XML MIME type. This could work, but it is limited to XML, and Apple wanted to allow authors to use HTML. Also, it requires that authors use two namespaces (one for the XHTML content, one for the Apple-proprietary content), and exposing authors to namespaces is a non-starter. The entire point of the Dashboard development environment is that it be trivially easy to write these applications, and namespaces are not trivial.
The fourth proposed solution is to simply replace the XHTML namespace with an Apple namespace, so there is only one namespace. This is even worse. Now not only would Apple be introducing three new non-standard tags, but they'd be introducing the whole of HTML as non-standard tags. No other browser would be able to render such pages. Accessibility tools would be unable to recognise the elements. Tools like Google would be unable to understand the semantics of the page for proper indexing.
The fifth proposed solution is to use a DOCTYPE that would enable
the extensions. This doesn't scale. What if another UA wants to
implement the extension as well? For example, marquee is
required by half the Chinese Web. Originally, only IE supported it.
Now take canvas, the Safari extension. If we had used
different DOCTYPEs for each set of extensions, which DOCTYPE would you
use if you wanted both? (And wanting both is quite likely; imagine a
stock ticker with a graph above it).
There are other problems with DOCTYPEs. Eric unintentionally reminded me of one when he said:
IBM already does something like this, having created an "IBM XHTML 1.1 Transitional" DTD that's used throughout their Web presence.
The IBM DOCTYPE actually had to be hard-coded into Mozilla to trigger quirks mode, otherwise their site wouldn't render right. It's also non-standard, and violates the HTML spec in several ways.
Eric continues:
If you run an IBM-XHTML compliant document through a validator that loads and uses IBM’s DTD to check over the document’s markup, then the document will validate.
This rather misses the point. It still won't be conformant. This is a key point. Creating a new DTD does not magically make you standards compliant. For example, here is a document that "validates":
<!DOCTYPE LI PUBLIC "-//W3C//DTD HTML 4.01//EN"> <li>Validation is only a small part of conformance.
I'm sure we all agree it's not conformant, though.
I've probably missed some of the other proposals. But the reality
is that it doesn't matter. If you want to make a proprietary
non-standard extension to a standard that doesn't support explicit
namespacing, you do the same as is recommended for
CSS: put your vendor name into the tag. In the case of the
aforementioned Safari extensions, I would have recommended calling the
new names apple-canvas, apple-composite, and
apple-search. The real solution is to
bring these proposals to the table, get some consensus between
the relevant vendors and other interested parties, and then use that.
For specific features like these, it doesn't take long to get
consensus; they are small features whose basic design can be agreed
reasonably quickly. Doing this also usually means getting wider
peer review, which improves the quality of the API.
For instance, it would have been pointed out that composite should
never have been put into the markup. It's presentational. It belongs in
the presentation layer, namely CSS.
Apple were probably concerned that by talking about this stuff, they would have tipped their hand about Dashboard. WHATWG is the perfect cover, though. Apple could have put forward their proposals, discussed them, got concensus, and everyone would have thought they were just planning these features for the Web Application space.
In fact, they did do this. Apple also introduced the new range
value for the type attribute of input elements, which
introduces a new control for imprecise numeric data entry (e.g. a
slider). This, as I mentioned
before, is not a proprietary value. This value was
discussed, in detail, on the WHATWG open mailing list,
and forms part of the Web Forms
2.0 draft specification. Here, Apple did the right thing: they
created an experimental implementation of a proposal. Their
implementation experience has already helped the draft (several
changes to the original text were made to more closely align with what
Apple found was actually needed).
So why did they not do this with the other extensions?
In other news, Brendan Eich gives us his take on the WHAT Working Group work and other issues facing the Mozilla Foundation in the latest edition of the Gillmor Gang. I highly recommend giving it a listen.