Categories
HTML5 Specs

Deprecated is now obsolete

A simple change can have profound consequences. What triggered this epiphany was my attempt to return the summary attribute to the HTML table element.

I thought all we would need to do to add summary back is remove the deprecated label from the attribute in the HTML table custom attribute list. But wait a second, when you look at the table element, there are *no custom attributes. All of the previously existing table attributes are now listed in the Obsolete but conforming or the Obsolete and not conforming section of the HTML 5 specification. Summary is joined by cellpadding, cellspacing, frame, rules, bgcolor, align, border, and width. The instructions associated with the latter attributes read, “The following attributes are obsolete (though the elements are still part of the language), and must not be used by authors”.

Now, most of the presentational attributes, such as bgcolor, were deprecated in HTML 4.01, so we had warning that these attributes could be made obsolete in future versions of HTML. Everything is right and proper to make bgcolor obsolete for Table in HTML 5. But what about those attributes, such as width, cellpadding, cellsummary, border, and yes, summary, that were not deprecated in HTML 4.01? Isn’t the proper procedure to, first, deprecate an attribute or element, and then obsolete it in a future version of the specification?

But the summary and other attributes are not deprecated in HTML 5. Instead, they have been tossed directly into the obsolete bin. In fact, if you look for these attributes in the table element definition, you won’t find anything but a toss away sentence for summary in the examples.

I thought the whole purpose behind deprecating language elements is so that if these elements are in widespread usage, it gives web authors notice that these elements can disappear someday. It gives people notice that they need to be prepared to change their web pages, without yanking the support rug out from under them while they make these changes? Look at the definition for “deprecated” in HTML 4.01:

A deprecated element or attribute is one that has been outdated by newer constructs. Deprecated elements are defined in the reference manual in appropriate locations, but are clearly marked as deprecated. Deprecated elements may become obsolete in future versions of HTML. User agents should continue to support deprecated elements for reasons of backward compatibility.

Definitions of elements and attributes clearly indicate which are deprecated.

This specification includes examples that illustrate how to avoid using deprecated elements. In most cases these depend on user agent support for style sheets. In general, authors should use style sheets to achieve stylistic and formatting effects rather than HTML presentational attributes. HTML presentational attributes have been deprecated when style sheet alternatives exist (see, for example, [CSS1]).

Clear, concise, and everyone understands what deprecate means. User agents still have to support the elements and attributes when they support HTML 4.01. Authors know they eventually have to modify their web pages to remove the attributes and elements, but that they’re still supported until they do.

Now look at the definition for obsolete in HTML 4.01:

An obsolete element or attribute is one for which there is no guarantee of support by a user agent. Obsolete elements are no longer defined in the specification, but are listed for historical purposes in the changes section of the reference manual.

Again, clarity. User agents know they don’t have to support the obsolete elements in HTML 4.01, though they do for older HTML languages. Authoring tools also understand that they should no longer support the attributes in new documents. In addition, there’s a historical reference to the elements/attributes so when we stumble upon the attribute or element in old web pages, we know when it bit the dust, so to speak. Authors definitely know that if they haven’t changed their pages by now, there’s no guarantees how those old, obsolete attributes and elements will be handled by user agents.

Compare and contract these with “The following attributes are obsolete (though the elements are still part of the language), and must not be used by authors”. Or the statement associated with summary, “Authors should not specify the summary attribute on table elements. This attribute was suggested in earlier versions of the language as a technique for providing explanatory text for complex tables for users of screen readers. One of the techniques described in the table section should be used instead.” Well, are the things obsolete, or not?

There is no continuity to this approach. There is no graceful movement from one version of the markup to the other. Instead, there is an abrupt transition that is guaranteed to leave confusion rippling in its wake.

“The following attributes are obsolete (though the elements are still part of the language), and must not be used by authors”. What does that mean? Does that mean user agents have to support the elements and attributes for an indefinite period of time? How about the summary attribute, which is obsolete but conforming? How can something be conforming and part of a language, and obsolete at the exact same time? Isn’t one aspect of a deprecated (and obsolete) attribute or element is that it is replaced by something else? Doesn’t physics preclude two bodies from occupying the same space at the same time?

There’s also a disconnect because the perfectly valid HTML 4.01 attributes are dumped into an also ran bin at the bottom of the HTML5 specification, leaving you wondering where the hell summary, or cellspacing, or cellpadding has gone. In HTML 4.01, when an attribute was deprecated, it was still listed with the element, but labeled deprecated, so you knew what the attribute was (if you see it in an actual page), and not to use it for new pages (deprecated).

It was an elegant process, for an elegant time. We gently pushed the no longer wanted attributes and elements over a hill and out of sight. We don’t have markup hills now, in HTML 5, we have markup cliffs. We haven’t taken attributes and elements over the hill, we’ve taken them to cliffs, and pushed them off. And the little buggers are grabbing hold of page designers and developers, not to mention authoring tools and user agents, to take with them on their way down.

By skipping over the entire concept of deprecation, and diving head first into making these elements and attributes obsolete, we’ve either redefined obsolete, so that it no longer means the same thing (“You’re gone!”), or we’re creating a massive level of uncertainty about how long we have to change our web pages.

My version of HTML 5 will return the concept of deprecated and obsolete to their old HTML 4.01 meaning, so that there is continuity between the specifications. In addition, the attributes that were not deprecated in HTML 4.01, but no longer wanted in HTML 5 will become deprecated in HTML 5, and eventually, possibly, gracefully made obsolete in a future version of HTML.

How will this impact on summary? The point of contention about summary isn’t that everyone loves the attribute and wants it to last forever, but that the accessibility folks want it supported in HTML 5 until something better comes along. Is there something better? The HTML 5 working draft lists various ways a person can document the structure of a table, but none of these ways fulfill the same purpose of summary. If they did, we could deprecate the summary attribute, with a reference to the replacement. But since these alternatives don’t serve the same purpose, summary has to continue as a viable, active attribute until replaced by something else.

The alternative approaches for documenting a table are also viable, and can continue in the specification, but they should be joined by an example demonstrating summary. In addition, summary needs a good description, at least to the same level of other elements and attributes, such as legend, section, and so on.

*Perhaps the fact that all custom attributes have been removed from the table element explains another reason why there’s reluctance to bring back the summary attribute: summary would look odd, hanging out there all by itself. Being the only table element custom attribute would actually emphasize the attribute, making it more likely that people would use it.

Categories
HTML5 W3C

Let loose the hounds of war

The space around HTML 5 just got more active, though whether what will follow will be an improvement in conditions is hard to say.

Because of a series of discussions in the W3C 2 cents emails list, a process is underway to provide a procedure whereby people can now act as their own editors of their own version of the HTML 5 specification. Eventually they’ll either be able to move their documents into Working Draft status, or petition to have sections in the current Editor’s draft replaced with their own sections. If consensus can’t be met on the petition, a vote will occur. Needless to say, you have to be a member of the HTML WG, but anyone can become a member. Just sign up for an account, answer a small questionnaire and you’ll be in. There’s even a FAQ for joining.

Much of the fervor around this move could be seen as a way of correcting the W3C’s chartering mistakes. Much of it, though, is also by people who are, they say, “tired of the complaints”, and see this as an effective approach to shutting up the complainers.

Though there’s nothing formally specified about numbers of participants on a new draft or draft section, Sam Ruby has requested that at least three people get behind any one work, just so the group, as a whole, can see there’s enough interest in the work to make the discussion and/or vote a good use of the group’s time.

Ian Hickson, the editor of HTML 5, has said that he’s asked for new editors in the past. Asked, and asked again. Well, now his request is being answered.

Categories
W3C

Survivor: W3C

If the W3C were a TV show, it would be Survivor, without a doubt. With the announcement of the less than graceful retirement of XHTML 2.0, the charitable would say that W3C is consolidating resources. The less charitable would say that in a face-to-face with the WhatWG and the browsers, the W3C blinked; or was voted off, to use the Survivor parlance.

Survivor Logo

Yes, XHTML will continue, but it’s a weakened XHTML, barely given enough oxygen to survive. In the wake of its rude abandonment, other affiliated groups, including the RDFa group, are left to scramble about as best they can to find a base. Sam Ruby of the HTML WG has encouraged them to jump into the HTML 5 web waters, and grab a copy of HTML 5 as a raft to ride to the future. I hope we will be forgiven, though, if we see the raft as a desperate, leaky ride, at best.

Players on a raft

Our web dims, as the lights of the consortium of web browsers— Mozilla/Firefox, Apple/Webkit/Safari, Google/Chrome, Microsoft/IE, and Opera—burn brighter. But wait? Wasn’t this the state of affairs a dozen years ago? Wasn’t the web of the future supposed to be a goal of what can be, not an infomercial of what is?

Why do I feel we have suddenly embraced mediocrity and called it gold?

Survivor picture

Those who beat tiny fists at walls surrounding HTML 5, are given a glimmer of hope: all they have to do is make a copy of the HTML 5 specification and modify it as they want, and if this doesn’t magically bring about consensus, why there will be some kind of vote and the best spec will win.

I wonder, though, will the vote take place with paper and charcoal, and names read off around a campfire? With some form of ritualistic extinguishing of the loser’s torch?

Torch being doused on Survivor

More:

I remind the new HTML 5 players of Survivor, and the concept of Alliance.

Survivor Players form an alliance

Categories
Standards

On XHTML2 and HTML5

I don’t have time at the moment to write anything in-depth on the recent decision of the W3C to let the charter for the XHTML2 working group expire. Instead, I’m going to list several interesting and/or relevant writings others have done, as both bookmarking for a future story, and for your edification.

I’ll probably add to this list over time.

update I have just filed my first formal objection with the W3C about the philosophy of one vote/one veto for the major browser vendors over any aspect of the HTML 5 specification.

What the one vote/one veto decision principle means is that if a company, such as Microsoft, states it will not implement, say, SVG in HTML, the Canvas element, or any other aspect of HTML 5— up to and including the entire HTML 5 specification — that it will be pulled from the HTML 5 specification. No discussion among the members of the HTML WG would be allowed to override this decision.

This is what replaces work on XHTML2. This is the future of your web.

Categories
W3C XHTML/HTML

XHTML2 is dead

XHTML2 news on Twitter

I have mixed feelings on this news.

On the one hand, I think it’s a good idea to focus on one X/HTML path.

On the other, I’ve been a part of the HTML WG for a little while now, and I don’t feel entirely happy, or comfortable with many of the decisions for X/HTML5, or for the fact that it is, for all intents and purposes, authored by one person. One person who works for Google, a company that can be aggressively competitive.