We received the below question from Guy Carberry who was wondering what effect changing the doctype on your HTML or XHTML pages to the HTML 5 doctype will have on those elements that are deprecated current draft.
There are several aspects to consider from this question so lets start by taking a look at Guys question in full.
Jeremy Keith says that we can change the Doctype declaration on XHTML 1.0 syntax pages to
<!DOCTYPE html> and it will immediately become HTML 5.
I’m a bit confused about what that means for the Absent and changed elements and attributes info detailed here: http://www.w3.org/TR/html5-diff/#absent-elements
“Some attributes from HTML 4 are no longer allowed in HTML5. If they need to have any impact on user agents for compatibility reasons it is defined how they should work in those scenarios.”
So if this is that case, how can you switch the doctype declarations and all be fine?
Thanks for your help,
The Doctors Response
In answering the question we will need to break the question down into the following:
- Which elements or attributes are deprecated?
- Do I use any of those elements or attributes on my site?
- How much do I need to worry about validation?
- What effect will this have for backwards compatibility?
- Can my content be accessed in all my target browsers and user agents?
Lets consider each of these in some more detail below.
1. Which elements or attributes are deprecated?
The elements deprecated (from HTML 4.01) from the HTML5 specification are:
basefont, big, center, font, strike, tt, frame, frameset, noframes, acronym, applet, isindex, dir
2. Do I use any of those elements or attributes on my site?
If your site uses any of the above named elements or attributes you may consider changing them to more semantic elements as introduced in HTML5. Alternatively you may decide to remove them and use CSS for presentation in the case of
Guy told use that he works for a large university. The site uses a large number of
<acronym> tags which have been removed from HTML 5 as detailed above. To solve this issue for Guy, I feel he has three options if he wishes to make the site: HTML5:
- Change the doctype to HTML5 and leave the
<acronym>elements in. (Bear in mind the HTML won’t validate)
- Change the doctype to HTML5 edit the
<acronym>elements to become
<abbr>elements as advised by the specification
- Do nothing and leave the site as HTML 4.01 or XHTML
It’s difficult to be able to advise Guy on which option he should choose without knowing the full extent of the effort involved to implement these solutions or knowing the sites goals and project teams views on validation. Speaking of validation, the whole area is a minefield and it’s what we’ll attempt to cover next.
3. How much do I need to worry about validation?
While validation is undoubtedly important for your markup and your CSS, in my opinion it isn’t crucial to a site. Allow me to explain, we recently received a couple of emails pointing out that this site doesn’t validate. While there were some errors that have now been corrected, a primary reason why is the use of ARIA roles in the markup. These attributes currently aren’t allowed in the current specification, however there is work underway to make this happen.
To illustrate this point let’s look at Google, the search giant. If you look at the source on Google’s search pages you’ll see they use the HTML5 doctype.
However, those pages don’t validate because they use the
<center> elements amongst others things that we already know have been removed from the specification. Does this mean that users stop visiting Google? No.
Remember too that the specification is yet to be finalised and may still be changed (thus breaking you’re perfectly valid docments), in partnership with this changes to the specification may not immediately take be implemented in the validators. We also need to bear in mind that HTML5 takes a “pave the cowpaths” approach to development, meaning that the Hixie, et al will look at what authors already do and improve upon it.
4. What effect will this have for backwards compatibility?
Leading on from the point about Google as mentioned previously we know Googles site not validating doesn’t matter but is it still backwards compatible? Yes. As far as we know, all the browsers support the
<font> tag. It’s the validators that don’t. If you want to use an antiquated element you can do, the browser will still handle it – it just won’t validate.
In terms of backwards compatibility there is no reason why you couldn’t start using new HTML 5 elements in your HTML 4.01 or XHTML 1.x documents, it could even be described as progressive enhancement. For example, why not include the
<video> element? It won’t validate but maybe that doesn’t matter? The browser will still be able to render video, hence
“paving the cowpaths”. Having said that if you’re going to the effort of including new elements why not go the whole hog and change the doctype too?
5. Can my content be accessed in all my target browsers and user agents?
Again to look at Google, it still renders in older browswers and devices but to all intents and purposes it’s HTML5. Another aspect that the specification defines is that new features should work in or not break in older browsers.
Remy pointed out in a response to Guy that
Remember that the browser is still going to handle this, regardless of whether HTML5 supports this or not. Just like and XHTML document although doesn’t validate with frames, it still renders fine and still supports frames.
So from that we can conclude that browsers will still render deprecated elements or practices.