HTML5 After a Glance

It’s been a little while since my last post, the reason for this being that I’m settling into a pretty rigorous schedule with my new contract, and have not had a chance to do much experimenting. After my last post, which was a response to Steve Jobs’ “Thoughts on Flash” article, I decided that my next little programming experiment should be to explore (at least preliminarily) HTML5 and start to formulate an idea for myself of the pros and cons of this new markup language.

This is exactly what I did last night, after a long day at work I decided that I really owed my blog a new entry and that in order to pay this debt I was going to have to do a little after-hours coding. That being said, I should make it very clear that I really only built a very simple layout using basic page elements, experimented a tiny bit with CSS3 transitions, and so I have not actually delved into the more powerful aspects of the language (such as the

As a markup language goes, HTML5 is much more intuitive than HTML has ever been. It has semantically logical naming conventions for all its tags (such as

, ,

and

) rather than just using

and relying on the id of the tag to identify its function. In addition, CSS3 has some very nice new additions as well, including dynamic shadowing for text, a built in border-radius property (which perhaps should be called “corner-radius”) which can be used to round the corners of page elements, and transitions which can be used to apply simple animations to page elements without using javascript to do so.

All in all, the experiment was a pretty painless experience, and for simple sites that conform to an architecture that isn’t stunted by using a standard markup language, I may begin to employ it moving forward. However, there are a couple really big concerns (for now) with HTML5/CSS3:

  1. It is an incomplete standard, which means that definitions and use cases will be changing over the course of the next several years. The implications of this are relatively extreme, as these changes may at any point require the re-programming of a site you build using the markup today. This will only be a concern until the standard itself is finalized.
  2. Browser support is currently limited, and backwards compatibility will require conditional logic AND javascript in order to deliver the same user experience via an older browser. Again, this issue will eventually work itself out, but it will most likely take longer to correct itself even than the first issue, for the simple reason that there are many different browsers, all of which tend to function slightly differently (at least from a historical perspective) and often do not support the same markup, css tags and plug-ins.

That said, I’m not sure exactly how developing an animated site using HTML5 at this juncture would necessarily save time or energy as compared to the level of effort that would go into building the same animated site in Flash or Flex, but certainly for some of the more simple implementations moving forward, it will become easier and easier to justify this as the standard moves towards finalization and the browser families become more compliant. I am extremely happy to see the HTML/CSS standards moving in a more logical, developer-friendly and robust direction, and I will re-iterate that this is all written after a very brief exposure to the new standard.

I’ll look forward to experimenting further and I will continue to report on my findings.

This entry was posted on Tuesday, May 18th, 2010 at 3:41 pm and is filed under All, HTML5, Interactive Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Leave a Reply

You must be logged in to post a comment.