Category: W3C

The most important point to remember during the review is to make sure you’re reviewing the correct document. You’ll want to review the W3C version of the HTML5 specification. Though the WhatWG group maintains a document that is frequently referred to as HTML5, it isn’t comparable to the W3C version of the document, as it does differ from the official W3C version of the HTML5 spec.

The IE Blog mentioned about making comments in the public-html-comments email list. This list is open to everyone, and you don’t have to be a member of the W3C or the HTML WG to send an email or subscribe to this email list. However, if you want your concern addressed within the HTML WG Decision Process, you’ll need to file a bug and do so before October 1st.

Prior to October 1st: Filing Bugs

If you find an error or want to submit a recommended change, and it’s before October 1st, you’re better off filing a bug against the specification. You don’t have to be a member of the W3C or HTML WG in order to file a bug. It’s easy and quick to create a Bugzilla account.

When you do file a bug against the HTML5 specification, make sure you file it against the HTML WG Product. When the bug entry page opens, select “HTML5 Spec (editor: Ian Hickson)” from the Components listed in the page. You can also file bugs against other components, but I’m focusing just on the HTML5 spec in this guide.

You should search through the bugs, first, to see if a bug has already been filed on the error you’re reporting, or the change you’re requesting. No worries, though, if you miss some bugs and end up filing a duplicate: someone will note that it is a duplicate, and process the bug, accordingly.

Provide as much information as you can. Try to be concise, but thorough. The fields you should focus on are the Summary field and the Description. The Summary is a title for the bug and the Description provides the details. You don’t want to change any of the drop-down values and you should be automatically added to the cc list for the bug.

If the bug is non-editorial—not related to fixing an error, including typographical errors—you’ll want to add the NE (Not Editorial) keyword to the keywords field. Adding this keyword also ensures that a copy of the bug is sent to the HTML WG members. If in doubt, leave off the keyword—it will be added by others at a later time. Also add other keywords as you deem appropriate. (Clicking on the Keyword label opens a page with the available keywords.)

If you’re new to filing bugs, there are bug writing guidelines.

Your bug could trigger a lively debate in the bug comments. Don’t be intimidated by the debate. Do join if if you think your doing so helps in determining how the bug is resolved. Don’t join in just to repeat your arguments over and over again, no matter how provoked. No one has ever been impressed with anyone because of what they say in a bug, so don’t try to impress anyone—communicate simply, cleanly, and succinctly.

The editor may not understand what you’re asking and ask for more information. If he does, provide the additional information, or ask him for clarification about what he needs. Don’t expect an immediate response. Some bugs have taken months to be resolved. However, with the new LC timeline, all bugs should be addressed by December.

If the editor agrees with you and modifies the HTML5 specification in order to resolve the bug, review the fix, and signal that you’re you’re happy with it by closing the bug. If you don’t agree with the fix, or if the editor marks the bug as WONTFIX, you have another option: escalate the bug to an issue. You do this by adding the TrackerRequest keyword to the bug. Eventually, the TrackerRequest keyword is changed to TrackerIssue and an issue number assigned.

If you’re following a bug but are not the reporter, and the editor resolves the bug and you’re not happy, you can also trigger a TrackerRequest. You don’t have to be the bug reporter in order to escalate the bug to an issue.

What happens with issues at this point gets a little tricky.

Once an Issue has been raised

Once a bug has been raised to an issue via TrackerRequest in the bug database, it’s made into an issue. All bugs entered into the database before October 1st that end up as issues enter the HTML WG Decision Process. The first phase in the process is to file a Change Proposal for the bug.

Technically, you don’t have to be a member of the HTML WG in order to file a Change Proposal. All you need do is grant ownership of the copyright of your proposal to the W3C and agree to the W3C patent policy. A procedure I’d recommend is to send the Change Proposal as an email to public-html-comments, copy the copyright grant and patent acknowledgment to the end of the proposal, and notify the HTML WG co-chairs of the Change Proposal. You should then be in compliance with the HTML WG Decision Process.

However, filing a Change Proposal when you’re not a member has never been tested, and when I attempted to do so, I received some strong push back. I still think it is a viable approach, but be forewarned that the HTML WG co-chairs may get bitchy about the whole thing. You might be better off just joining the HTML WG. Unless you work for a W3C member, you can easily join the group as an Invited Expert and it doesn’t cost you a penny.

The co-chairs will call for a counter-proposal once you’ve filed your change proposal. If none is filed, the co-chairs will ask for a Call for Consensus on the proposal. If counter or alternative proposals are filed, the co-chairs will make a decision based on all of the proposals—the new Last Call timeline does not include any time for surveys. If you disagree with the decision, and you feel strongly about the issue, file a Formal Objection, covered later.

Filing a Bug after October 1st and Last Call Comments

Bugs filed after October 1st are handled differently. Instead of going through the bug/issue/decision process, the bug is automatically labeled a Last Call comment.

A Last Call comment is equivalent to a working group issue but without the formal change proposal/counter proposal. LC Comments have to be resolved in some way in the working group before the specification can proceed to the next state.

You can also post LC comments to public-html-comments but you might want to make a note in the subject line that you want the comment to be treated as a Last Call comment—or otherwise designate that the comment as something that requires an HTML WG response. So that LC comments sent to public-html-comments can be referenced with a specific identifier and tracked, they will be entered into the bug or issues database.

What Should you say, and how should you say it

The HTML WG may end up with a Last Call comment template, similar to what’s provided for change proposals. Generally, though, there’s a couple of things to keep in mind when writing your comment.

The HTML WG and the HTML WG co-chairs (not to mention the W3C team rep, contact, and Director) want technical discussions. They like technical discussions. Social discussions, or discussions that border on anything related to beliefs, feelings, or global goodness leaves them cold, which then leaves your requested change out in the cold. This means you should word your concerns using technical terms as much as possible and, if relevant to your concern, provide a technical solution.

You don’t have to write a book. In fact, assume that the HTML WG has exactly five minutes to devote to your comment or change proposal, so cover the important bits and leave your inner James Joyce at home.

If your comment or proposal generates discussion, do participate, but do so carefully. There are discussion guidelines for all email groups within the W3C, and there’s an additional Discussion guideline for the HTML WG. To rephrase what the guidelines say:

Participate, but if you find yourself repeating what you’ve said earlier, then stop. And if people disagree with you and you don’t have anything new to add in response, just thank the person, say you disagree, and let it go.

Use a neutral tone of voice. This is tough, because we all know that we’re right and those idiots are wrong. But pretend those idiots are your beloved, white haired old granny, who would be horribly hurt if you responded the way you would like to respond. So treat the idiots kindly and respectfully. If nothing else, a calm, measured response will drive them crazy.

And now, I want to tell you about the wild squash plant in my garden. No, not really. Now I want to mention how you have to stay on topic in the discussions. If you don’t, the co-chairs, otherwise collectively known as “Dad”, will send you a “tut tut” email. This email is going to irritate the hell out of you—so stay on topic.

Of course, I’m one to give advice, considering that I have had some significant difficulties with members of the HTML WG. All I’ll say is that I’m not completely to blame for the problems but I’m not blameless, either, which is usually the way these things go.

For one, I was overly persistent—getting my teeth into something and not letting it go, long past the point when anything useful could be dragged from the discussion. It was bad enough if the topic was technical in nature, but I would also do so about group procedures, and this was the equivalent to fingernails on a chalk board for some in the group.

In addition, I can be a bit of a know-it-all in the discussions. There’s a fine line between being confident of your viewpoint, and being arrogant, sarcastic, or pedantic, and I crossed this line more than once. Sometimes I did so unknowingly; other times, because I was angry or frustrated, or was responding to what I perceived to be know-it-all behavior in others. Regardless of reason, it’s not an effective communication technique.

If you do participate in a debate about your comments or change proposals in the mailing lists, and you recognize both behaviors in others or yourself, just stop. And if you do find yourself getting pissed, walk away. You’ll live longer, and your cat won’t be afraid of you.

Formal Objections

Hopefully, in all of the proposal, counter-proposal, LC comments, and related discussions, decisions will get made most people can live with and the HTML5 specification will progress. Since much of the document has no independent implementations, the W3C will most likely make a call for implementations. During the implementation phase, more problems may be discovered, and there will be additional time for reviewing or filing bugs.

If you find, though, that there was a decision you can’t live with, you do have one final option: file a Formal Objection. A Formal Objection is the procedural equivalent of a missing end tag in an XHTML document: it generates a draconian response. Formal Objections go the Director, otherwise known as Sir Tim Berners-Lee. Sir Tim invented the inter-web tube thing. Sir Tim is a very busy man. I also have the impression that he doesn’t suffer fools gladly. If you’re going to file a Formal Objection, you better make sure you know what you’re doing, and follow the procedure for Formal Objections exactly.

Ah, but we all know that the community interested in HTML5 is an easy going cooperative group, so why worry about things like Formal Objections?

OK, enough with procedures: let’s get onto the document.

If you’ve seen the HTML4 specification and are expecting something similar, you’re in for a surprise and not necessarily a pleasant one. The HTML5 document differs significantly.

The HTML5 document not only includes the markup syntax you would expect but it also includes the Document Object Model (DOM) for the HTML elements, as well as the parsing algorithms recommended for applications such as browsers. This leaves us with one very big document that is geared to multiple audiences. What you have to do, then, is dig through the document for the bits that interest you.

From the top:

Section 1: The Introduction

The first section provides an overview of the HTML5 specification and should be read by all audiences. It provides some background information and sets the stage for what follows. It also provides a description of the typographical conventions used in the document.

There’s two phrases that appears in this section and others: normative and non-normative. What non-normative means is that the section is provided for information purposes but isn’t definitive. The normative stuff is the rules and requirements bits.

Section 2: Common Infrastructure

This section is geared more towards application builders, primarily those building HTML parsers, browsers, or utilities. It should also be of interest to web applications builders because it introduces the DOM. Folks interested in HTML elements and their syntax may find most of this section a bit difficult to plod through. However, there is one section, Section 2.2.2 covering Extensibility, that is of interest to authors, as are the sections about general syntax for items such as colors.

Another phrase is introduced in this section: non-conforming. What this means is just what it says: if you do something that’s non-conforming, your document won’t be considered conforming. Oh, your page should still work fine in browsers and other applications, but you’ll get lots of grumbles when you run the page through a validator. I’ll have more on conforming, as compared to deprecation and obsolete later.

Section 3: Semantics, Structure, and APIs of HTML Documents

Section 3.1 is focused more on web application developers and browser builders, so web authors and designers can probably give it a pass. Section 3.2 gets into the structure of HTML elements, and should be read by everyone since it provides basic background for all of the HTML elements. Section 3.2 also contains a reference to the ARIA (Accessible Rich Internet Applications) mappings, so it is especially important that those folks interested in accessibility carefully review the material.

For those interested in accessibility, I also recommend that you check out another document, HTML5: Techniques for providing useful text alternatives. And do check back, in case some of the ARIA material ends up in a separate document, or is significantly re-written. In addition, expect either a new document or section on media accessibility for the new media elements. Support for accessibility is one area of expected change in the HTML5 document in the next several months.

Sections 3.3 through 3.5 are again focused at web developers rather than authors and designers.

Section 4: The Elements of HTML

Section 4 is the money section of the HTML5 document, providing a list of all the HTML elements. Everyone needs to go through this section, but not every component of the section needs review. As I mentioned earlier, the HTML5 specification merges the DOM APIs in with the HTML syntax, so the coverage in this section skips between audiences.

As a rule of thumb, the element syntax and use is covered in the first part of the sub-section related to the element, while the API is covered in the latter part. Many of the elements—such as nav, section, article, div—don’t have unique API needs, so there isn’t an associated DOM section, as they all share the API for one object, HTMLElement. The API for HTMLElement was covered earlier, in Section 3.2.

However, some elements, such as the new audio and video elements, do have their own unique DOM needs, which are covered following the discussion about the element syntax. Note, though, that web application functionality is interwoven among the syntax description, so expect to have to jump about a bit. Regardless, web authors should read through the entire section and just ignore the programmatic bits.

There are some new form elements, but most of the new form functionality comes from newly added form input types, which are covered in Section 4.10.7. It’s a bit tricky going through this section, as implementation of the new form functionality is sporadic, at best. Wikipedia has a table that shows which form input type is implemented in which browser (among other things). What you can look for in this sections is inconsistencies that would normally be driven out in implementation (or that could create havoc if implemented, as is).

There are also new form attributes, such as autofocus, placeholder, and the like. Most of the new attributes have been implemented in at least a couple of browsers.

Section 4.11 is labeled “Interactive Elements” and web authors may assume this section is about JavaScript-related functionality and think to skip it. However, this section covers many of the new declarative elements, which require no JavaScript. Declarative elements are ones where the functionality is baked into the element rather than implemented with code. As with form input types, though, many of these new declarative elements have not yet been implemented by any browser.

There’s a section titled “Common idioms without dedicated elements”. Oh, I’m really trying to get rid of this section. It’s best to let usage derive organically, rather than try to dictate it within a web specification. Feel free to read the section, but remember all of the material is this section is suggestion, only.

There’s also a document you may want to glance through that covers just the elements and their syntax, HTML: The Markup Language Reference. It might be a lot easier to read, though you should review the HTML5 document for bugs and concerns during this Last Call process.

Another document of interest is the HTML Canvas2D Context, which covers the guts, if I may use such an indelicate term, for the Canvas element. If you’re interested in working with Canvas, you’ll definitely want to check out this document.

Section 5: Loading Web Pages

This section and the next are actually old friends that are under new management. If you’ve worked with JavaScript applications in the last ten years, you know about the Window object, History, and so on. You also know that this functionality has never been standardized. Well, it is in HTML5.

It’s good to see this functionality finally standardized. Unfortunately, and there’s little disagreement about this, it really doesn’t fit within an HTML5 specification. However, trying to separate it out from the document was something none of us wanted to attempt—not without a guarantee that the effort wouldn’t be disregarded and rejected by the powers-that-be.

This section is for web and application developers. The page load processing model might be of interest to web authors and designers curious in how it works, but the focus of this section really is on developers. And web application developers should give this section a very careful perusal, because they may find some of their existing web applications no longer working as expected because of what’s documented in this section.

Section 6: Web Application APIs

The title tells you what you need to know, upfront: this is for developers. This is the remaining components of what used to be known as the Browser Object Model, and also includes an overview of event handling, events, and timers. Web authors and designers can also give this section a pass.

Section 7: User Interaction

Everyone is going to want to go through Section 7. It describes new attributes, such as hidden, and standardized versions of functionality, such as drag and drop and contenteditable. What’s interesting about this section is that we’re looking at a blend between functionality and structure, which is going to create a challenge for those building web sites. Should the structure components be added by designers, such as the use of the hidden attribute, or the drag and drop attributes? Or do the application developers add these in using JavaScript when the pages are loaded?

Web page authors should go through the section to understand what you can do with a web page. Web application developers should peruse it more carefully; to review the functionality for possible gotchas and future problems.

Section 8: The HTML Syntax

This section provides an overview of the HTML syntax, but the description is given from a browser parsing perspective, rather than in language geared to web authors, and even web developers. If you’re a web author and developer, do feel free to look through the section, but if you find yourself losing interest in the first few paragraphs, you can probably skip this section.

The section that might interest you the most is Section 8.1.2.4, which covers optional tags. This tells you when you can or cannot omit tags. It’s not easy to follow, but it can help you determine why you’re having problems with your documents, and getting all those errors and warnings when you test your documents in a validator.

Section 9: The XHTML Syntax

If you’re like me, and mostly use XHTML for your documents, give this section a once over. However, you may also want to examine another document, HTML/XHTML Authoring Compatibility Guidelines. This document provides an overview of the differences in syntax between HTML5 and XHTML5, including quoting attribute values, closing elements, and so on.

Section 10: Rendering

Now this is an interesting section. This is where the HTML5 editor is providing guidance about how elements are to be rendered. It’s important to note, though, the following disclaimer in the very start of the section:

User agents are not required to present HTML documents in any particular way. However, this section provides a set of suggestions for rendering HTML documents that, if followed, are likely to lead to a user experience that closely resembles the experience intended by the documents’ authors. So as to avoid confusion regarding the normativity of this section, RFC2119 terms have not been used. Instead, the term “expected” is used to indicate behavior that will lead to this experience.

To me, the use of expected sets expectations, but you can’t depend on this. As we are finding, how many of the new elements and form types are rendered does differ between browsers and operating system, and there’s little we can do to style most of the elements.

Look through the section, note inconsistencies, and file any concerns.

Section 11: Obsolete Elements

Earlier I mentioned about the non-conforming phrase. Unlike HTML4, the concept of deprecation is no longer supported; neither is the concept of validation. Now, a use of an element or attribute is conforming or not, and an element can be obsolete but conforming, which is the HTML5 version of deprecation. In addition, elements and attributes no longer go through a deprecation period, first, but can be labeled immediately obsolete, such as the longdesc attribute.

The whole point on this change is that supposedly no element or attribute will ever not be supported by user agents, which is something that deprecate and obsolete imply in earlier versions of HTML. I’ll be frank and say I don’t agree with this change or philosophy, or the entire obsolete but conforming designation, or making elements and attributes obsolete without first deprecating them. There is an issue on this currently (Issue 106), but no change proposals. However, I am filing a LC Comment on this section, and the concepts.

In the meantime, look through the list, see if you can spot any old friends among the newly dead.

Section 12: IANA Considerations

Of interest to application and web developers, but probably not of interest to web authors and designers.

That’s the last of the sections. Note that you don’t have to rush out today and begin reviewing HTML5, because the formal call for Last Call comments won’t happen until next April or May, and you’ll still have a period of time to comment, following. However, the sooner you do file concerns and bugs, the sooner they’re addressed (and the sooner they’re implemented the way you want).

Have fun.

Still no updates on my issues at the W3C HTML WG, but the co-chairs did decide on the fate of longdesc, the focus of another issue:

the HTML Working Group hereby adopts the Change Proposal to not include the longdesc attribute in the language. Of the three Change Proposals before us, this one has drawn the weaker objections.

This is a highly controversial decision, not the least of which because the HTML WG Accessibility Task Force had recommended longdesc be kept, and the HTML WG co-chairs have disregarded the recommendations of its own task force. In addition, other standards documents in the W3C, as well as elsewhere, not only recommend longdesc use, but also mandate its use (if appropriate) if a site is to conform to law.

The argument for dropping support for longdesc I found to be most disconcerting is the following:

The weakest proposal was the one that makes longdesc conforming but with a warning. The primary rationale given for this proposal was that a few sites may be using longdesc properly. Many of the objections to both of the other proposals also apply to this one. Additionally, there was a strong argument which is unique to this proposal: if longdesc is conforming, user agents will be required to support it; if there is a validator warning, users will be discouraged from using it. This combination is the worst of all possibilities. Eliminating this proposal early made the process of coming to a resolution simpler.

The existence of implementations was found to be a weak argument for inclusion, the quantify of bad data was found to be weak argument against inclusion. External references (standards, laws, etc) was also found to be a weak argument for inclusion.

The strongest argument against inclusion was the lack of use cases that clearly and directly support this specific feature of the language. The fact that longdesc has little observable uptake amongst users reinforces this: all the evidence indicates that users don’t see this feature to be compelling, and the lack of user demand has been noticed by implementors.

This entire section is extremely confusing, for multiple reasons. The first is that the section is describing what happens when a component of a language is deprecated—a concept that has been successfully utilized in technology for as long I can remember. The whole purpose of deprecation is that an element that has been previously supported is no longer, suddenly, not supported. The sudden cessation of support of an element between two releases of a language, library, or API causes confusion, as well as potentially introducing a great deal of breakage as people advance their applications from the older language or library, to the new.

In a mature, thoughtfully designed language or library, what happens, instead, is that the element is supported in the next version of the language, but a warning is given about its use. The warning instructs the user that they may use the element this one last time, but support for the element will most likely be pulled in a future version of the language, or application. The warning should also inform the individual about the preferred approach to take in the future. The use of deprecation ensures that people can gracefully advance their applications to the new release, and still have time to modify existing uses of the previously supported elements.

So the fact that the one of the proposals recommended deprecating the element rather than just making it suddenly obsolete, was considered a weak argument leaves one to wonder: what could possibly be a strong argument?

Of course, one of the primary problems with deprecation in HTML5 is the fact that deprecation isn’t supported in HTML5. No, we now have the new concept of obsolete, but conforming. Whereby deprecation is long known to be a way of gracefully moving a people from the use of one component to another more preferred approach, obsolete but conforming seems to be a way of saying—well, frankly, I don’t know what it’s supposed to be saying. Something profound and extremely clever, I’m sure.

Another reason I found the earlier quote from the co-chair decision to be confusing is that the existence of external laws and standards requiring support for longdesc is also considered a weak argument.

In what world, my friends?

To disdain external standards, not to mention government mandates, is extremely arrogant and incredibly short sighted. It is as if the HTML WG is attempting to undermine the credibility of the W3C. I don’t believe this is the intent but is, instead, a by-product of the obsessive focus, in both the HTML WG and the WhatWG, on meeting the interests of only one group when it comes to determining what’s in HTML5: the browser companies. The so-called Implementers.

Though it is true the browser companies—Apple, Google, Opera, Microsoft, and Mozilla—need to be on board with whatever is released in HTML5, it should also be a given that the browser companies, themselves, should be interested in meeting the needs of their community of users—and this includes the accessibility community, in addition to web developers, designers, other tool builders, and so on.

The HTML WG co-chair decision was, frankly, poorly reasoned. That people will formally object is a given. That the formal objection will succeed is also a given because the W3C has no choice but to reject this decision. The W3C cannot afford to be so cavalier as to arrogantly pronounce itself above government and other organizational mandates. The browser companies may deem themselves to be above such consideration, but the W3C cannot be so short sighted, and thoughtless. The W3C also cannot possibly afford to undermine its own credibility by introducing conflicts between its own recommendations: to recommend longdesc in one of its documents, while, at the exact same time, making it obsolete in another. The whole point of deprecation is to prevent such anomalies from occurring.

Folly. Pure folly.