Year: 2010

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.

Summary

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.

Rationale

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.

Details

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="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Example Table</title>
<style>
table
{
  border: 1px solid #ccc;
  border-collapse: collapse;
  margin: 0 20px;
}

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

.female
{
  background-color: #ffc;
}

tfoot
{
  font-size: smaller;
}
</style>
</head>
<body>
<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.">

   <caption>
      <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.
      </p>

   </caption>

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

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

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

   <thead>
      <tr>
         <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>
      </tr>

      <tr>
         <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> 
      <tr>
         <th>Male</th><th>Female</th><th>Male</th><th>Female</th><th>Male</th><th>Female</th>

         <th>Male</th><th>Female</th><th>Male</th><th>Female</th><th>Male</th><th>Female</th>
      </tr>
   </thead>
   <tbody>
      <tr>
       <td>2002</td><td>22,918</td><td>37,186</td><td>41,950</td><td>15,483</td>

                    <td>2,981</td><td>4,009</td><td>13,267</td><td>6,242</td>
                    <td>2,804</td><td>2,289</td><td>648</td><td>168</td> 
      </tr>
      <tr>
       <td>2003</td><td>23,248</td><td>38,261</td><td>44,585</td><td>14,903</td>

                     <td>3,227</td><td>4,430</td><td>13,868</td><td>6,275</td>
                     <td>2,804</td><td>2,438</td><td>709</td><td>200</td> 
      </tr>
      <tr>
       <td>2004</td><td>24,617</td><td>39,994</td><td>42,125</td><td>11,986</td>

                    <td>3,318</td><td>4,881</td><td>13,136</td><td>5,280</td>
                    <td>2,845</td><td>2,733</td><td>905</td><td>214</td>
      </tr>
      <tr>
       <td>2005</td><td>26,651</td><td>42,527</td><td>37,705</td><td>9,775</td>

                    <td>3,654</td><td>5,027</td><td>12,470</td><td>4,585</td>
                    <td>2,933</td><td>2,842</td><td>1,109</td><td>307</td>
      </tr>
      <tr>
       <td>2006</td><td>29,951</td><td>45,200</td><td>34,342</td><td>7,828</td>

                    <td>3,568</td><td>5,179</td><td>11,985</td><td>4,247</td>
                    <td>3,221</td><td>3,133</td><td>1,267</td><td>328</td>
      </tr>
   </tbody>
  
   <tfoot>

      <tr>
         <td colspan="13">Data from Institution of Education Sciences National Center
                for Education Statistics, derived from two tables: 
                <a href="http://nces.ed.gov/programs/digest/d08/tables/dt08_298.asp">
                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="http://nces.ed.gov/programs/digest/d08/tables/dt08_302.asp">
                Table 302. Degrees in compueter and information sciences conferred by degree-granting 
                 institutions, by level of degree and sex of student: 1970–71 through 
                 2006–07</a></td>
      </tr>
   </tfoot>
</table>
</body>
</html>

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.

Impact

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.

References

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8449

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.

References

[1] http://blog.whatwg.org/whats-next-in-html-episode-1/comment-page-1#comme…