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.

Print Friendly, PDF & Email