Beast-Blog.com
Will the Road to HTML 5 be Rough?

I am really impressed with the HTML 5 work being performed by Ian Hickson, as the draft editor, and the others who are part of the WHATWG. I’m a fan of the work, and I believe it has promise. From the updated meaning of some of those gray area elements, to the deprecation (made obsolete) of some of the garbage that has littered the web for the past fifteen years, to the introduction of new elements that will offer organizational value where none exists today, to the introduction of new attributes to give all elements clearer meaning, it all bodes well with me. But I cannot help but wonder how we will get there.

Some Probable Issues

As I see it, current user agents will never be able to understand the value of the new elements — or use them as styling hooks for that matter. Internet Explorer (IE) 6, even version 7, for example, will be in use by some percentage of the population for at least ten more years. I don’t have a link for you, and I have no proof of concept, this is my gut talking, but I’d be willing to bet on it. Some people are slow to change and will simply never be current, no matter how much the rest of the world wants them to. Sure you could say the heck with them and that they need to get with the program, but those of us who go through the trouble making our sites accessible will always have difficulty foregoing the needs of anyone, even those using Internet Explorer 6 in 2018.

It is because of this that the use of current elements will have to persist for quite some time. This on it’s own won’t be an issue for user agents of the future, they will detect the DTD as they do now, and will support HTML 4 if that’s what’s being served. As stated in the HTML 5 differences from HTML 4 document being edited by Anne van Kesteren:

HTML 5 is defined in a way that it is backwards compatible with the way user agents handle deployed content. To keep the authoring language relatively simple for authors several elements and attributes are not included as outlined in the other sections of this document, such as presentational elements that are better dealt with using CSS.

User agents, however, will always have to support these older elements and this is why the specification clearly separates requirements for authors and user agents. This means that authors can not use the isindex or plaintext element, but user agents are required to support them in a way that is compatible with how these elements behaved previously. — 1.2. Backwards Compatible

Browser makers would be crazy to forgo HTML 4 support for decades in all likeliness. You and I both know there with be table-laden web sites bristling with font tags for a long, long time. The question in my mind is not backwards compatibility, but rather the impossible forwards-compatibility of older user agents still in the use and how we will deal with that issue. How and when will developers be able to make a safe segue into the land of HTML 5?

Some parts will be easy. I am extremely pleased that the strong element no longer means strong emphasis, but rather it now signifies importance. I also like how clearly defined the abbreviation elements abbr and acronym are — an acronym is an abbreviation that is spoken as a word, like radar (regardless of initialisms because that was never clear anyway). These are in practice now on sites I build and within the content I write. The latter is my personal recommendation in fact.

Right now I’m all over any elements currently supported. In other words, I am swiftly applying HTML 5’s new and improved meaning to the elements contemporary browsers will recognize. Any movement beyond that, though, is where things start getting tricky. If I want to use the new section element, instead of a div, how will I make sure my site stays backwards compatible? How does one make the leap to HTML 5? Will it happen fully by 2023… okay, who goes first? First a strategy session.

Some Possible Solutions

Here are some my thoughts about ways to deal with this situation. To move ahead without forgetting the past. To retain accessibility and usability to the user agents in use today without stagnating.

No Styles is Passable

This is inevitable. At some point, we will offer the page to users of today’s browsers sans styles. This will be fine from an accessibility perspective, the semantics will be no different than they are today (not improved with new elements and attributes), but style-based usability enhancements and content layout will be lost. It’ll be quite like our Netscape 3 and IE 4 offerings today.

Some Old, Some New

Both could be used. A div with a section, with styling applied to the div until some point in the future. You’d have to, unless you sensed the user’s browser (but I’ll get to that soon). This is a usable transition method, but it could almost double a page’s main structural markup. If one were to do this, new attributes would have to be applied to the new markup, and the currently supported attributes applied to the old elements — and new ones, too, in many cases. Also added to the old elements one might possibly add the new irrelevant attribute to indicate to a future user agent that some of the old elements are no longer applicable.

Sniffing & Redundancy

I mentioned above “unless you sensed the user’s browser” by which, of course, I mean “browser sniffing.” Before you groan, this might be a good method. I wouldn’t rely on JavaScript for this. I suspect that as long as web security is a concern, some people will turn if off and some companies will stop it at the door. I prefer, and can offer, a decent PHP browser sniffer (not to be used in security applications, but it’s good for dishing out a style sheet). What it could do:

• A browser sniffer could be used to initiate another server-side script that finds and replaces certain elements in files called for in HTTP requests.
• It could be used to call a different template or HTML page. The former would be fine on database-driven sites, the latter would be a lot of hard work.
• A browser sniffer could be used in combination with the idea of using old and new markup in the same file. That way styles could be applied to the new elements on new browsers, and applied to old elements for old browsers.

Note: If you were to apply a scripted find-and-replace solution as mentioned in the list above, you’d probably want markup pages with something like (note the commented closing tag):

<!--Find this-->
<div id="section_content">
</div><!--section_content-->

<!--Replace with-->
<section id="content">
</section>

Who, Me Worry?

I’m not sweating this transition, I have confidence it’ll work itself in time. It’s just the period in between that I question. I suspect conditionally-served style sheets and hacks for IE will probably be with us for a while — as long as old models exist. One concern I do have, if I can properly read the writing on the wall: Will people be saying how antiquated HTML 5 is once it’s fully adopted by all sites and all user agents, and mostly being properly implemented, at around the time some of the web movers and shakers are working diligently on HTML 6?

Filed under Access Counts, Coding & Markup —

Bookmarking Links » del.icio.us | Digg | blogmarks | StumbleUpon | Technorati |

These posts may be related:

Book Smarts or Street Smarts? »

Experts Perform Jaws Testing »

Starlight Journey »