As many of you may be aware, validating your pages in HTML5 has become a whole new adventure.
Along with changes in what now constitutes “valid” and “invalid” markup, the HTML5 Validator (which, by the way, is the same tool that runs the W3C’s HTML5 validator) will provide some warnings about obsolete features in HTML5.
Feel free to go through that document on the W3C’s site, but here I’ll touch on some things that you may want to be aware of with regards to obsolete elements and attributes.
There’s No More “Deprecated”
Many developers will be familiar with the word “deprecated” when referring to elements and attributes that no longer validate or that are no longer part of the current HTML spec. This was the term used in previous versions of HTML, but not with HTML5.
So, for example, if you validate a document using an XHTML Strict doctype, and you use the <iframe> element or the target attribute, the validator will output the two errors shown in the screen grab below:
This has changed to a large degree in HTML5. In the case of <iframe> and target, those features are now valid in HTML5, so there’s no problem–the page will validate and there won’t be any warnings.
Obsolete But Conforming Features
Let’s try instead to validate an HTML5 document that contains obsolete features that are still considered valid in HTML5. Here’s a screen grab of the message you’ll see if you validate a document that uses an <img> element with the border attribute, in addition to an <a> element with the name attribute (both attributes of which are now obsolete in HTML5 in those contexts):
So, according to the HTML5 validator, the page is still valid, but you are warned to instead use alternative methods to accomplish the same thing.
For a full list of “obsolete but conforming” features see the appropriate section in the same W3C document.
Totally Obsolete Elements
On the other hand, some elements are just downright wrong and should not be used. So you won’t just get a warning, you’ll get a full-blown error with a recommendation to accomplish the same thing in a valid manner.
Some of the error-inducing obsolete elements include <applet>, <acronym>, <frame>, <noframes>, <strike>, <big>, and <blink>. You can see a full list of non-conforming obsolete features here.
Will Obsolete Features Break Your Pages?
Generally speaking, no, these invalid elements will not break your pages. The HTML5 doctype is not a doctype to identify a markup language, it’s a doctype to identify a web document, whether it’s using old elements or new stuff like <nav> and <section>.
I know I’ve probably oversimplified the definition of a doctype here, but generally speaking, that’s what is happening. That’s why it’s okay to change old documents to an HTML5 doctype without fear of your pages breaking or rendering differently.
Also, browser makers are required to support those old obsolete elements. That same document contains a section called Requirements for Implementations, which basically tells browser makers how obsolete elements should be handled when the page is rendered.
Of course, when we say that browser makers are “required” to do this, it’s not as if they’ll be arrested or fined if they don’t; it’s really just a recommendation, but I think for the most part browser makers have complied.
I guess if anything, this should help further drive home the point that it’s okay to to start changing pages with old doctypes to the HTML5 doctype. It’s true that the pages may not technically validate anymore (in most cases they will), but they will still render the same.
I believe in HTML5 and in CSS3. And I use them, as it is possible, browser-patched and browser-incomplete, today, to build web pages.
The alternative would be just naive. When one is arguing that it’s not using them because there are browsers that don’t support them, or that the browser support is only partial, they should also mention the fact that there are browsers among those above that have partial support for CSS 2.1 too. What then? Stick with CSS 1? ‘Till when?
And HTML5 is a better “transitional” then every other attempt made before to help build a long standing and friendly standard for web developers, if only that.
As I read it, will still be part of HTML5 ?`
—— snippet from http://dev.w3.org/html5/spec/obsolete.html#requirements-for-implementations —-
* frame
* frameset
* noframes
Either use iframe and CSS instead, or use server-side includes to generate complete pages with the various invariant parts merged in.
or am I wrong?
Ehm, I forgot to remove the brackets on the word iframe.
What I am saying is:
“As I read it, iframe will still be part of HTML5 ?”
Yes, frames in the form of iframe will still be a part of HTML5 (and not obsoleted)
I remember a discussion with Chris Coiyer and some other guys some days ago about this topic.
If you see how Twitter, Facebook and many others use iFrames for their services you cannot think of a website without them. There are great possibilities to use an iframe I think.
It’s more of a choice then a forced deal.
You could use <object> instead of <iframe>, with the usual older IE versions headaches.
Good article, it resulted in interesting comments.
I haven’t used HTML5 that much yet.
These discussions give me a good feedback for my future projects.
Even though I am not into html, this site provides me with insights about the same and how it can be used to create stunning websites. I shall bookmark this page and visit it again in the future.
Yes there is.
<frame><frameset><noframes>and<applet>are deprecated, alongside others.Those elements aren’t “deprecated”, they’re “obsolete”. That’s what I’m explaining in the article. They’re no longer referred to using that term in HTML5, we now use the term “obsolete”.
Good article, it resulted in interesting comments about Html 5.
Tanks!
Thanks for good article!
Some times i can’t beleive we are so far behind on HTML5 at least the publics idea of web browsing is. Google Dev I/O had some great things to say about it at last years confference, anyway keep up the good work, i know i need to adjust my own site to html5 http://www.creativeautomaton.com.
Good article, Thanks for the info!
Thank you, very helpful article.
i dont like html 5
I love the html5… it has more features… but it didn’t support to many browsers…
Thanks for this best article, really helped a lot
Bookmarking it.
Great article Louis. Pleased to hear that invalid elements shouldn’t break pages.Some great insights. Keep up the good work!
Thanks for this information, this link is made to spread it…
You say
What do you gain if you chage doctype to HTML5? I mean, what would be the point of changing doctype, if you won’t use any HTML5 elements?
There would probably be little point. But there are a few reasons you might do it. The fact is, you could use an XHTML doctype and still use many HTML5 elements. It really doesn’t matter.
I guess it’s more of a ‘support the latest standards’ thing. And using a simpler doctype means fewer bytes per page, so it does have a benefit, albeit a minuscule one.
My feeling is, if you’ve got your doctype in an include file, and you can change it in a single spot for the whole site, then go ahead, change it. But if you have to change it in multiple places for very little benefit, then don’t bother.
That’s a good for html5. That’s what I’m explaining in the article.
That’s good for coding . nice post dude
Thanks for the informative post Louis, death to the Applet tag!
i don’t love html5 :) i wait for more developent.
another great article on html5… very helpful and easy to understand!
Interesting article Louis. Some really useful and relevant stuff. Many thanks.
Easy validation with HTML5! Why would anyone use anything else?
If anybody is interested, I made a bookmarklet to help with getting rid of the obsolete attributes in your HTML. Check it out here: http://keithwyland.github.com/attrebuke/
Thanks for sharing another great article!