Obsolete features to watch out for during revision of old pages

[weegillis]

I took the plunge last night and began switching a live site to HTML5. The task was not all that daunting, but it did make me eat some of my words. Just because a site is valid HTML or XHTML, does not necessarily make it valid HTML5. It is because of the obsolete features that this was the case for me. Once I got them in the bag, everything was ship shape, at least for this phase. The site segment that I revamped is still largely old code that needs to be thought through and tagged with the new semantic tags. That should be fun.

Here is a list of the Obsolete items as described on W3C:

W3C: Obsolete features.

Scroll down to table and get a gander at that section. Tables are taking on a stricter role, and layout is not in the mix; ergo, the summary="" empty attribute is obsolete.

What other validation issues are folks running into?

[keyon]

Most of what I've read about W3C validation (in general) is that it's not necessary to comply -- websites have been working just fine with or without the validation for the last ten years. So when I read what W3C says about HTML5, I get the impression that maybe it's the same deal? Once again, they give us this enormous to-do list, using scary words like "obsolete" and "warning" and "violation." But in reality, is HTML5 any less forgiving than HTML4?

[weegillis]

Last question first:

But in reality, is HTML5 any less forgiving than HTML4?

HTML5 out of the box is roughly the equivalent to Strict.dtd in HTML and XHTML. It follows the XML strictness to a tee. So no, it is not less forgiving. We need to pay heed to the fact that it switches the browser to standards mode automatically. There is no way to switch to quirks mode using this doctype. A whole array of detritus is ignored or choked on, depending on UA.

Strictness applies to the parsing user agent. If the UA has no give, then only valid code can be parsed. Looseness covers the other extreme, that of deprecated and obsolete tags and attributes. HTML 4.01 Transitional uses a loose DTD, as does XHTML Transitional, still validating although rife with deprecated and obsolete tags, etc. HTML 4.01 and XHTML with the strict DTD will only validate to strict specification. These earlier doctypes can all trigger quirks mode.

Again, where this matters is in the strictness of the UA. Some user agents offer absolutely no support for loose code and have no quirks mode to fall back on. Only the strict elements will be regarded, if any. The result can be ugly when we send a loose document to that UA. It will either render a mess, garbage or nothing at all.

Browsers on the whole are actually miles ahead of the game, but their vendors are just not on the same page, yet. Nobody wants to see the internet fall apart or break over night. This is why it takes years to actually drop support for old tags. These are not the user agents we're targeting with STRICT DTD's. It's the other ones used by assistive technologies and content aggregating robots, etc. Much of their technology is based on XML, not one of the browser flavors. In order for our code to work in those UA's, it has to be parsed out and recompiled as XML. You can see where things can quickly go wrong when garbage is fed into this algorithm.

I'm saying this but can't remember where I read any of it. Fortunately we're at the stage where there is really not a lot of authoritative writing, so it only takes a couple of weeks to chew through the more salient articles. Most books on the subject are hot off the press. If you find that anything I say is wrong, come right back here and call me out on it.

So when I read what W3C says about HTML5, I get the impression that maybe it's the same deal?

Yes and no. This time there's more heads to roll. LOL. Actually, this time around there is more collaboration and community working (cooperation) between all the big players, and W3C is responding to the recommendations coming out of the working group. The process is much more transparent than before, so we really can get a bead on what's on the menu. There will be wrestling yet, but we can see that the spec is dialling in nicely. With what is in place now, we can expect little to change in the next couple of years. The spec will harden and before we know it the rest will be forgotten.

... websites have been working just fine with or without the validation for the last ten years.

This is true. And you look at many sites, they are running TRANSITIONAL when they don't care to validate. It's not a requirement, unless you want to ensure that your code will render in a strict UA. Some search engine robots are strict. For this reason it has always been encouraged to create as valid a document as you can. It can have a bearing on how well rendered your document is in the Cached Page. But for the most part, pages don't need to be valid to be indexed or ranked. This is old news.

Validating every page you write will take forever. Validating a page or two generated by a template is usually enough. The idea is to determine if your document is well formed, uses currently accepted tags and attributes, or contains any misspelled or incorrectly implemented syntax.

Validating generated pages is usually futile, we know they won't validate. It's in the generated code that we stuffed all the invalid things, like target="_blank" for instance. Serve up clean, valid code to the UA, and let the DOM serve out all the less than valid code in plug-ins, mail links, new windows, etc.

[weegillis]

I just discovered that support for rel="last" on the LINK element has been dropped. There is an archived WHATWG "hixie' on the subject, here: hixie: Drop support for rel=up, rel=last, rel=index, rel=first, and any related synonyms. (whatwg r5924).

At this point in time I have pages validating with next, index, contents, & author on the site I'm currently working upon. So it would appear they are, and possibly will remain supported in future recommendations. I'll return to this post with others no longer supported as I run across them.

Update: rel="first" is not supported; rel="previous" is. Still discovering...

[Keimos]

Hi,

I agree that good code practice should be followed, it allows for cross browser rendering to render the pages the same, however as you have already pointed out, the DCOM of the browser will be backward compatible to allow for user friendliness. Something, I don't think we will ever escape.

Regards
Keith