The Word Wide Web has grown at an astounding pace and is pretty ingrained in a lot of our daily lives – you’re reading it right now. Part of the reason it has been so successful has been the flexibility and ease of use of the basic language of web pages, HTML.
Most web sites are developed in HTML 4 (first released in 1997) or XHTML (from 2000). Considering the rapid change all around the web, why hasn’t there been a new version, and what’s next for the Web? One reason we haven’t seen new versions is the aforementioned flexibility. There have been plenty of developments, from blogging software and other content management systems on the server side to CSS, AJAX, and embedded Flash video on the front end.
Microformats are a part of this and will be a big part of the future too. But all the web developers in the house should get up to speed on HTML 5, which looks to be the future of the Web.
I’ve been watching what the Web Hypertext Application Technology Working Group (WHATWG) has been doing with HTML 5 ever since I took a gander at the W3C’s XHTML 2 spec and figured out that they were mostly adding annoyance and removing backwards compatibility. Guys I respect, like Eric Meyer, seemed to agree. The WHATWG decided to work on their own ideas and came up with HTML, which was eventually adopted by the W3C as well.
I haven’t taken a look in a while but Marcia Zeng mentioned the HTML 5 spec in an email recently and it got me interested in checking back in. I have to say, for the most part, it’s looking very interesting.
So I decided to put together a quick list of my top 10 new things in HTML 5:
- The <nav> element. This will be great for the billions of navbars we web developers have been coding up for the past 10 years. Things like this will help reduce the problem of div soup and make structure more apparent.
- The <header> and <footer> elements. See the last entry and add in the billions of page headers and footers we’ve produced as well. Semantically meaningful tags like these can only help browser plugin writers, search engine programmers, and other hackers to come up with cool new features.
- The death of the dreaded <font> tag. This should have been banished as soon as CSS was widely supported. It was a pain in the rear to use back in the 1990s when coding by hand, and was even worse when inserted by GUI tools like FrontPage.
- The continued usefulness of the <img> element. You may be wondering how we could make web pages without the image element, but XHTML2 only included it grudgingly, recommending everyone use <object> instead. The problem is that just about anything could be an object, the tag is almost meaningless. Why not replace all tags with <thing>?
- The <audio> and <video> elements. There’s been some controversy about this, because the W3C originally recommended use of the open source Ogg formats but later recanted. Still, it will be nice to embed audio and video as easily and consistently as images are used now.
- New <input> types for dates, urls, etc. When you have a form that requires a user input a date or some other specialized data, you choices have been to present a plain text input or jazz things up with JavaScript to make it a bit more usable. HTML 5 adds specific types for these cases.
- The conenteditable API. This will be really interesting if it’s fully supported. In Tim Berners-Lee’s original vision for the web, documents would be easily editable. Wikis get us almost there, but a standard editing API would be even better.
- A required attribute for form inputs. This won’t mean we can stop checking incoming data on the server side (users can still POST arbitrary data with the right tools) but it should remove the need for millions of little field-checking JavaScripts.
- The <figure> and <legend> elements. This will make it a little easier to associate captions and other text to images. Look for CMSs and image search engines to take advantage of these tags.
- An open development process. Want to keep an eye on development? Got an idea or concern about the spec? Hop on one of the mailing lists. Open standards are great for promoting compatibility and competition, so open development of the standards just makes sense.
i’m not sure why you think it will be so good, since you just use WordPress anyway
I do use WordPress for this blog, and two of the reasons I chose it was that it is open source (so I can alter the code and write plugins) and it generates standards-compliant code.
It will be fun to see what the WordPress community comes up with newer standards like HTML and maybe put together a plugin or two myself.
Technically, the W3C doesn’t recommend the spec whatsoever until it is published a REC (HTML 5 is currently a pre-working-draft editor’s draft). Anything in it should represent the consensus of the WG at the time it is written.
As for WordPress, I have my doubts. Everything that has ever been said within WP is that they’ll support XHTML as it’s newer and therefore better.
That’s good point, Geoffrey. So, to anyone reading, don’t take this post to be a list of new tags and attributes you can start using right now. It’s just a heads-up on where things seem to be headed in the future.
Great!
What will be the available formats for the <audio> and <video> tags?
I don’t see the usefulness of HTML5. To me, it is adding a mixture of semantic elements and purpose elements. I prefer XHTML 2.0 over HTML5 as they stand right now. Here is my opinion on the spots you referenced:
– This is useful, just as XHTML 2.0 appears to still include the (navigation list) element.
, – Why do we need these? XHTML 2.0 will have and elements. They aren’t necessarily used for just text.
– It has been deprecated since HTML 4.0. XHTML 1.0 allowed for Strict, Transitional and Frameset only for compatibility with older HTML. With XHTML 1.1, that will be gone, just as it will be with HTML5, so really it isn’t the WHATWG’s idea to drop the tag.
– Yes, I think the death of the tag is a good thing. Why? Well, for one thing, any element can include an image using the @src attribute. In fact, the W3C addresses this change in http://www.w3.org/TR/xhtml2/introduction.html#s_intro_differences
, – encompasses both though. It makes more sense to have one element that does that. Not only that, but if and are provided, where are and and and the others? works for them all. It was meant to be a multi-purpose element where things like didn’t fit. After all, is only for images.
and its special types – This is what scripts are for – validation of user input. This doesn’t belong in HTML. That’s all I’ll say about it.
contenteditable – This is actually a pretty good idea. The W3C already halfway does it with their Amaya browser/editor, and Firefox’s Web Developer Toolbar add-in has an Edit HTML and Edit CSS feature that gets us halfway there.
@required – It could be useful in some cases, but generally, there is an acceptance of the asterisk next to a form field denoting a required input. One might even mark it up as * for screen readers that read the title instead of the text enclosed by the start and end tags. For that reason, I’d say this isn’t very necessary.
, – I thought things like this are what and CSS were for. And in the case of XHTML 2.0, they aren’t very necessary anyway with the ability to use @src on any element, and then using CSS for a caption.
Open development process – isn’t this one reason why the W3C’s mailing lists were created, to hash out the various redundancies and useful, yet improperly defined/described, aspects of the languages they govern?
I’m not saying that WHATWG’s HTML5 is bad, but I would rather have something with more semantics, like XHTML. Not only that, but XHTML 2.0 will be able to integrate with other XML-based languages because it is XML itself. In fact, that can be done now with the Modularization of XHTML. I do hope that HTML5 does become somewhat popular, so that the efforts of those who worked on it won’t be wasted.
Just because someone uses WordPress doesn’t mean that they do not have an interest in development. I use WordPress on my blog because I needed to get a site up quickly and it was the best way to do it.
I am personally most excited about the <font> tag finally going away. I hated that thing – and the constant explanation of it to my students. Explain it, then explain why not to use it.