Web spec goulash

The biggest mistake associated with the HTML5 specification is also the only mistake that can’t be corrected: the charter. The charter allowed the group to create an HTML and XHTML serialization, as well as an associated DOM. Unfortunately, the interpretation of this charter was such that all three tasks have been combined in one document, and that’s been a problem with both scope and audience, ever since.

In the past, the HTML document has been separate from the XHTML serialization, and from the Document Object Models. By being separate, the documents are kept small, and the audience is well defined. A web page author or designer would feel comfortable reading the HTML4 document, directly, and not be confronted with material focused at web developers, or worse, User Agent developers.

We in the HTML WG know this, and seemingly don’t. We’ll include any amount of author information in the HTML5 specification on the one hand, but on the other, make statements about how the web page authors won’t actually read the document—they’ll go to some tutorial or guide. We seem to have a difficult time making up our mind as to the HTML5 spec’s audience.

I think we’ve gone beyond being able to split the HTML, XHTML, and DOM into separate specifications. Unfortunate. Our next best option is to ensure that whatever is in the specification is only related to HTML, XHTML, and the DOM. We can start by splitting out the User Agent specific material, currently included in Sections 5 and 6, as we split out Microdata and the Canvas 2D API.

If we’re successful in splitting out the browsing context, a second step is to consider moving out much of the author guidelines into a separate specification. This would allow us to expand on these guidelines, while also helping to trim the 600 or so pages that currently make up the HTML 5 specification.

Of course, this isn’t going to work while the HTML5 spec and most of the split off sections are still controlled by one person. This is an unhealthy situation. A situation that, unfortunately, can’t be fixed by filing a bug, or raising an issue.

Graphics/CSS HTML5 JavaScript

Declarative Elements versus JavaScript and CSS

Over time as I looked at several of the new elements in HTML5, I saw a trend: many of the elements are single purpose derivations of popular, and commonly occurring, JavaScript and CSS applications. Consider the following list:

  • the progress element
  • the meter element
  • the hidden attribute
  • the details element
  • the telephone input type
  • the email input type
  • the search input type
  • the color picker
  • various date pickers

As I wrote in one of the change proposals, any one of these would have be welcome ten years ago, when HTML4 was released. But now, after we’ve come so far with using JavaScript and CSS, not to mention SVG and the Canvas element—what is the lesson we’re learning from these additions?

Ten years ago, support for CSS and JavaScript was poor enough that something like a color picker was almost impossible, unless you used Flash. Now, though, there are dozens of good libraries available that can implement a color picker. Drupal’s color picker is based on the jQuery UI, but it’s not the only option.

We’ve also had date pickers for years, too. Date pickers in all shapes and sizes, and most configurable by the user so they can get the absolute best date picking experience. The same can be said for progress bars, and if meter is supposed to represent a gauge, there are libraries that provide gauges, too.

As for the input types, such as telephone and email, most of the validation for these types of values can be handled with one line a code and a regular expression. The types also beg the question: where does it end? If we need single purpose data types such as telephone and email, why stop there? What about social security number for people in the states, or zip and/or postal codes?

One of the primary reasons for regular expressions in JavaScript is to ensure that a given string fits a given format. If we don’t know how to use regular expressions, that’s OK, because just like the iPhone, there’s a app for that. There are many libraries that automate the format validation for us. All we have to is assign a class to the relevant input fields.

The new elements, attribute, and input types aren’t just treading in JavaScript and CSS territory. Supposedly the reason for the hidden attribute is accessibility, as is a reason for several of the other elements. Yet the WAI-ARIA effort has provided the exact same functionality and semantics that can be used and reused with any number of elements.

ARIA is to accessibility, as JavaScript is to behavior, as CSS is to style, as RDFa/Microformats/Microdata are to semantics, and as HTML is to structure. Except, suddenly, HTML is no longer about structure. The clean separation between the various domains that has worked so well in the past is seemingly no longer of interest to the HTML WG. Consider the following statement in the HTML5 specification:

Authors are encouraged to use declarative alternatives to scripting where possible, as declarative mechanisms are often more maintainable, and many users disable scripting.

For example, instead of using script to show or hide a section to show more details, the details element could be used.


The arguments I’ve read are that declarative alternatives can be used by non-developers, but they’re no easier for non-developers to use than most of the JavaScript libraries I know, which usually only require adding a class to an element.

I’ve also read that declarative alternatives aren’t impacted when JavaScript is turned off, but in my opinion, that’s not a good thing. People have become used to JavaScript-based functionality on the web. They know if a section is exposed via JavaScript that turning off the JavaScript should display the section by default. People can control JavaScript and Flash in their browsers, which means they can control the behavior of the web page. They can also turn off CSS, if they wish. But they have no control over declarative elements and animations.

Consider, too, the costs involved with all these new elements and other objects. Rather than browser developers focused on making the most efficient JavaScript engine, the most secure browser, adding support for SVG and Canvas, Video, WebGL, and any of the other new technologies, the developers now have to focus on what is nothing more than a duplication of functionality already available via libraries, apps, and widgets. Which they also have to support through the core technologies of CSS and JavaScript.

Then consider all of the HTML editors and WYSIWYG tools that now have to add several new input types and elements, including having to provide a live preview of the functionality. Implementing all these new elements, attributes, and input types must seem a daunting task.

How about the web authors and designers? New toys, eh?

New toys that lack both the sophistication and customization capability that we’ve had with our existing libraries. New toys that aren’t accessible until we can convince the screen readers that no, seriously, not only do they have to support ARIA, they have to support all these other new things, too.


Issue 92


Summary: Replace too-simple and somewhat odd example table and verbose text unrelated to the table element, with one example table, derived from real world data that best demonstrates the table element. Refocus the text specifically on the table element.


In the bug[1] related to this issue, the HTML5 Editor’s rationale for not make this change was:

Rationale: Given how bad the current situation is regarding authors providing explanatory text for tables, I think we should given them as much information as possible, in as many places as possible. We do AT users a disservice if we pretend that their needs aren’t important enough to include advice on how to best serve them in the spec.

The current table element section provides one very small and inadequate table example, with a great deal of prose basically telling people what to put in text surrounding the table. None of this prose is related to the purpose and interoperable use of the table or its child elements, and seemingly added to the section only as a way of justifying removing the summary attribute. I hate to use cliches, but this seems like a true case of the tail wagging the dog.

Throwing lots of irrelevant text at authors does not make the table element any clearer, or ensure they use the element in the proper way. What’s needed is a good, succinct example, with a clear explanation of the element, and the table’s only unique attribute, summary.

What people incorporate into the text surrounding an HTML table is not the business of the W3C HTML Working Group. Such over-specification only adds to the noise, and if you throw enough noise at people, all they’ll do is tune out the important bits.

The space would be better used by providing a table listing that uses all of the table child elements, demonstrating how the elements work together, and then providing a screenshot of the table. By creating a listing, people can see how the table is put together; the figure demonstrates the visual rendering of the table.


Replace the existing table element description section with the following (replace the URL for the img element in the figure with one local to the W3C, image can be copied, link table model):

The table element represents data with more than one dimension, organized into non-empty columns and rows. It is the primary component of the table model.

Tables are used for data display, only, and should not be used for layout purposes. In particular, users of accessibility tools like screen readers are likely to find it difficult to navigate pages with tables used for layout.

The only unique attribute for the table element is the summary attribute. This attribute is optional, and should only be used with complex tables, in order to provide a visual description of the structure of the table—making the table easier to navigate when rendered non-visually. The summary may also include a brief description of the purpose of the table, if such purpose is visually apparent when viewing the entire table, but may not be apparent traversing the table, cell by cell. An example of a complex table is shown in Listing Table-1. Figure Table-1 is a visual rendering of the table.

<!DOCTYPE html>
<html xmlns="" xml:lang="en" lang="en">
<title>Example Table</title>
  border: 1px solid #ccc;
  border-collapse: collapse;
  margin: 0 20px;

td, th
  border: 1px solid #ccc;
  padding: 10px;

  background-color: #ffc;

  font-size: smaller;
<table summary="First row is column headers separated into year and degree programs 
                (bachelor, master, graduate). Each degree program is further split into 
                biology and technology fields on second line. Each topic field is separated into 
                male and female graduates on third row. Years are listed in first column.">

      <p>Degrees in the biological and biomedical sciences compared with degrees 
         in technology conferred by degree-granting institutions, by level of 
         degree and sex of student: Selected years, 2002-2007.


   <colgroup span="1"></colgroup>
      <col class="male" />
      <col class="female" />
      <col class="male" />

      <col class="female" />
      <col class="male" />
      <col class="female" />
      <col class="male" />
      <col class="female" />

      <col class="male" />
      <col class="female" />
      <col class="male" />
      <col class="female" />

         <th rowspan="3">Year</th><th colspan="4">Bachelor's Degrees</th>
         <th colspan="4">Master's Degrees</th>
         <th colspan="4">Doctor's Degrees</th>

         <th colspan="2">Biology</th><th colspan="2">Technology</th>
         <th colspan="2">Biology</th><th colspan="2">Technology</th>
         <th colspan="2">Biology</th><th colspan="2">Technology</th></tr> 







         <td colspan="13">Data from Institution of Education Sciences National Center
                for Education Statistics, derived from two tables: 
                <a href="">
                Table  298. Degrees in the biological and biomedical sciences conferred by degree-granting 
                institutions, by level of degree and sex of students; selected years, 1951-52 through 2006-07
                </a> and <a href="">
                Table 302. Degrees in compueter and information sciences conferred by degree-granting 
                 institutions, by level of degree and sex of student: 1970–71 through 

Other changes:

For each of the table element children in the listing—tr, th, col, colgroup, caption, tbody, thead, tfoot—reference the existing example in Listing Table-1, and remove any other example table. One example should be sufficient to demonstrate all of the table model elements.

Though this is more related to Issue 32, it’s still relevant: remove the warning about the summary attribute, and remove the attribute from the “obsolete but conforming” section. We’ve beat this horse so much that it’s practically glue. Time to open the gates and let it loose. Time to move on to other things.


Positive Effects

Replaces an unbelievable table example, with one that is believable, using real data. In the spec, we should avoid contrived and made up examples, as much as possible, as they can undermine the credibility of the section, and distract from element(s) being demonstrated.

The change also clarifies the section and puts the focus back on the table element, rather than anything but. The example also demonstrates how to use all of the table elements, as well as making a correct use of the summary attribute. Linking all of the table child elements back to the table element section and the listing allows people to see how these elements are used, especially in context.

Negative Effects

Will take some of the editor’s time to make this change. The use of labels such as Listing Table-1 and Figure Table-1 may not fit it within the writing style of the rest of the specification (adjust as necessary). The listing is also a little large, though as a demonstration of a family of elements, not overly so.




HTML5: When will the madness end?

I have come neither to bury HTML5, nor to praise it.

I didn’t think any word could get more overused than Web 2.0, but HTML5 has come close. You can’t go to a tech conference nowadays without HTML5 being mentioned through lips moist with anticipation. Companies are profuse with their promises of HTML5 support, even if they don’t have a clue what “HTML5” is, and whether it’s even relevant to their businesses.

We’ve heard it’s going to kill Flash, squash proprietary technologies like Silverlight, beat Microsoft into submission, combat all evil in the world, and I’m sure, if given a faux diamond crown, would also bring world peace.

We’ve also heard that it is nothing more than a pipe dream, with a implementation date decades in the future, controlled by a megalomaniac with an evil cabal of “do no evil” companies as backup singers. It is hailed as both the triumph and the death knell of the W3C.

Everyone who works with the Web knows HTML5. Ask most folks, though, what is HTML5, and they’ll either mention technologies not directly associated with the HTML5 effort, such as geolocation, or they’ll focus on a couple of the more glitzy components, such as Canvas and video, and some vague references to new semantic elements.

HTML5 is both more and less than the assumptions surrounding it.

You’re not going to read about geolocation in this small book. Neither are you going to read about Canvas or video, though I do have strong opinions about both. No, I’m going to talk about that other stuff that makes up HTML5: the little things, such as individual elements and attributes; and the bigger things, such as the philosophies governing what is, or is not, included within the HTML5 specification. Not random topics, either: all of the items I’m covering are either related to an existing HTML WG issue, or bug; all of the items have been picked because they represent four major areas where I feel the HTML5 specification has…challenges

First, a little background. I’ve been working off and on with the HTML5 working group, known as W3C HTML WG, for some time now. I am an invited expert. Don’t be impressed, in only means I don’t do this for pay. I didn’t have to do anything extraordinary to become an invited expert. Unlike some other efforts at the W3C, the HTML WG is a remarkably open group: anyone can join, barring membership company restrictions. You don’t have to travel to the face-to-face meetings held once or twice a year, attend the weekly teleconferences, vote or respond to any of the polls.

In fact, you don’t have to do anything to be a member of good standing in the W3C HTML WG. If you consider that currently there’s over 400 members, but the last time a poll was taken, only about thirty people responded, well, you can see that “good standing” probably means still breathing, and not so obnoxious that you’re kicked off the group—and some would say that you have to be pretty damn obnoxious to get kicked off, as no one has been forcefully removed. Yet.

Also unlike many other W3C groups, including past efforts for HTML and XHTML, the HTML5 specification aonly has *one editor. Well, author, really, since the person doing the editing, Ian Hickson, is also the person making many of the decisions about what’s included.

The HTML5 specification is currently under administration by two organizations, rather than one: the W3C, and the Web Hypertext Application Technology Working Group, otherwise known as the WhatWG. The WhatWG originated with a small group of people, and still consists of only a small number of members. Back in 2004 or so, the WhatWG folks became frustrated with the direction the W3C was taking with XHTML. They decided to begin their own work, first in private email discussions, and then later at the WhatWG web site and email forum. According to the front page for the organization, dated 2004, and found at the Wayback Machine:

The Web Hypertext Applications Technology Working Group is a loose, unofficial, and open collaboration of Web browser manufacturers and interested parties aiming to develop new technologies for the easy deployment of interoperable Web Applications.

The creation of this forum follows from several months of work by private e-mail on specifications for such technologies. The main focus up to this point has been extending HTML4 Forms to support features requested by authors, without breaking backwards compatibility with existing content. This group was created to ensure that future development of these specifications will be completely open, through a publicly-archived, open mailing list. Working drafts of the specifications will be continuously available on the WHATWG Web site. As the drafts reach stable milestones, the group will publish snapshots for extensive review by the community.

Well, we’ve gone beyond work on HTML4 Forms.

In 2006, after the browser companies said “Bad Dog! No biscuit!”, the W3C signed on board with the WhatWG, leading to the alliance we have today. A many times uneasy alliance, and therein lies one of the more challenging aspects of working with HTML5. So challenging, and frankly, so contentious, that the W3C HTML WG co-chairs, Sam Ruby, Paul Cotton, and Maciej, decided to create a Decision Process to handle editor/member disagreement.

How the process works is that we file bugs against the HTML5 specification. Doesn’t matter how small or large the bug, it has to begin with a bug. Then the editor either decides to make an edit to the document based on our bug, or marks it WONTFIX, in which case one of two things can happen: nothing, or someone disagrees with the editor’s decision, and escalates the item to an issue. From that point on, the issue goes through a change proposal process, which is what led to me writing this small book.

I have ten change proposals to write by March 31st, and I decided to group the effort in this publication for a couple of reasons. First, I’ve been working on a Drupal ePub theme in order to easily convert Drupal books into actual ePub books, and this seemed like a way to have a little fun with the change proposal process. Second, there’s information I wanted to communicate that doesn’t fit within the rather inflexible boundaries of the W3C HTML WG Decision Process.

Information such as, how long can this dual group thing continue? In a comment to the WhatWG weblog[1], Marcos Caceres wrote:

You know, it’s really great that people are thinking about the future of HTML. But it troubles me that this work is being done outside the W3C for a number of reasons. The WHATWG does not have a patent policy, nor does it have a wide representation of all stakeholders (browser vendors are not the sole custodians of the Web, as represented by the WHATWG invite only membership). It’s also troublesome that Opera, Apple, and Mozilla retain copyright over the document, without a proper license (“You are granted a license to use, reproduce and create derivative works of this document.” doesn’t define what those terms and limits are, which is a threat because one particular company in the group is know for it’s predatory pursuit of IPR violations). As a start, maybe WHATWG HTML should be under a world-wide CC license. Better still, why can’t this be done as an open incubator group at the W3C? The W3C got it’s ass kicked by the WHATWG wrt XHTML and XHTML2. The director already admitted they fucked up royally and gave the WHATWG everything they wanted (killed XHTML, made a totally open WG). I don’t see what role is left to be played by the WHATWG apart from continuing to undermine the work and membership of the W3C and continue to push their solutions on the rest of the community. I think it’s wrong that the WHAT-WG believes it owns the canonical version of HTML and should stop attempting to undermine the W3C and its membership.

What a lot of people don’t know about the WhatWG is that it is nothing more than a web site. It is not a legal entity, so it cannot grant licenses, or otherwise give any form of legal permission. The only one who can, is Ian Hickson. He owns the web site, it’s served on his server, if it goes down in the middle of the night, it stays down until he’s up the next morning to get it started again. His is the only name on the HTML5 specification at the WhatWG web site.

The browser companies may have kicked the W3C’s ass, but they also need the W3C, as much as the W3C needs them. The W3C is a legal entity, does have a patent policy, knows how to ensure companies can work together and no one gets clobbered with IP issues. We also have to assume that if the server goes down in the middle of the night, it doesn’t stay down until Tim Berners-Lee gets up in the morning.



SVG Technology Writing


I’ve not been the best at keeping up with my writing at my various sites. I have been writing, though.

I have a two-part article up at A List Apart: Using SVG for Flexible, Scalable, and Fun Backgrounds, Part 1 and Part 2. Though Microsoft still hasn’t implemented SVG in IE, with the company’s new membership in the SVG Working Group, there’s new hope for the future. And I cover how to use a JavaScript library, SVGWeb, to work around the lack.

I’m also finishing a new book for O’Reilly: the JavaScript Cookbook. It promises to be a big book, which isn’t surprising, considering how much JavaScript has advanced. I’m also incorporating the relevant bits from the HTML5 specification, though I have to be careful, as we don’t know which bits will remain, and which removed before Last Call.

Speaking of which, I’ve been spending an inordinate amount of time with the HTML WG. I have about a dozen Change Proposals coming up in March, which I’ll write about here, when finished. Among them is one to remove one of the more recent additions, the iframe srcdoc attribute. This example for this new attribute is the following, for weblog comments (the use case for the new attribute):

 <h1>I got my own magazine!</h1>
 <p>After much effort, I've finally found a publisher, and so now I
 have my own magazine! Isn't that awesome?! The first issue will come
 out in September, and we have articles about getting food, and about
 getting in boxes, it's going to be great!</p>
  <p>Written by <a href="/users/cap">cap</a>.
  <time pubdate>2009-08-21T23:32Z</time></p>
  <footer> At <time pubdate>2009-08-21T23:35Z</time>, <a href="/users/ch">ch</a> writes: </footer>
  <iframe seamless sandbox="allow-same-origin" srcdoc="<p>did you get a cover picture yet?"></iframe>
  <footer> At <time pubdate>2009-08-21T23:44Z</time>, <a href="/users/cap">cap</a> writes: </footer>
  <iframe seamless sandbox="allow-same-origin" srcdoc="<p>Yeah, you can see it <a href=&quot;/gallery/cover/1&quot;>in my gallery</a>."></iframe>
  <footer> At <time pubdate>2009-08-21T23:58Z</time>, <a href="/users/ch">ch</a> writes: </footer>
  <iframe seamless sandbox="allow-same-origin" srcdoc="<p>hey that's earl's table.
<p>you should get earl&amp;amp;me on the next cover."></iframe>

Just in case you’re curious, no, I’m not particularly fond of weblog comments as escaped HTML within an attribute on an iFrame.

I’ve also been playing with the new Drupal 7 alpha in my copious spare time. I won’t be moving my sites over to Drupal 7 until a stable release, but I do have a “play” site. I like the new release, though I wasn’t terribly fond of the admin overlay. However, the new admin overlay can be turned off. In addition, I re-posted all of the pages, and comments, from my older WordPress weblog. It takes up little room, and ensures I can find, and link, some of my older work. Plus, folks can find their comments. I was impressed with the fact that WordPress was able to upgrade my old site, without a hitch.

So much to write, so little time. Today, though, it’s snowing, and I haven’t had a walk outside since the weekend. Enjoy the articles at A List Apart, and more writing here, soon.