HTML5: Handle With Care


Praemonitus praemunitus

(Forewarned is forearmed)

Latin proverb

You obviously have met a “Read Carefully” section in virtually any agreement or proposal—whether they were printed or on-line. Despite the appeal, this part is intentionally made unreadable using ALL CAPS or tiny font. Why? It doesn’t that matter as soon as all goes well, but any non-standard move welcomes you to the “Read Carefully” trap – you lost. HTML5 has comprehensive overviews, tutorials, but misses that so vital section. In this article I’ll try to fill in this gap.

Why it’s that important? Because as of now (September 2012), HTML5 is the only option for long-term web development ('Thoughts on Flash', by Steve Jobs, CEO of Apple, Inc., Future of Silverlight: is this technology outdated already?). The change to pure-HTML5-world may happen in several years, it will be HTML69 or rather a new attractive (for innocent users) brand name, but the core idea will survive: there is no need for patches—yes, patches—for commonly demanded features. Besides multimedia and graphical content, HTML5 offers even a way for representing math formulae, so the future of the plugins seems to be restricted to very specific purposes—the original goal the plugins had been intended for.

As a seasoned developer, I use to doubt about “new” “breakthrough” technologies. Most of them are just re-branded dusted good ol’ ideas (e.g. The model-view-controller pattern was originally formulated in the late 1970s), many have not gotten to be time-proved (for multiple examples, please open 5-10 year old web pages). What category HTML5 fells into? Is this just an extended version of 15 year old HTML4? How much stuff it’s adopted from the ivory tower of XHTML? Anyway, there are no products without flaws; we need to be aware of their light and dark sides. So, HTML5 – read and handle carefully.


Lever with no Place to Stand.


Give me a place to stand and with a lever I will move the whole world.



Voila! The management approved using HTML5, and the developers started studying this new technology. It has so many useful features that HTML4 deserved since the end of dial-up era! Hmmm… my mobile connection is hell slow, could you lend me that box with a label “14400”, I noticed you used it to stipulate connections. Oh, much better! What’s the name of that unit? Modem? It stands for “mobile demo”, huh?

Lesson 1. Regardless of ubiquitous high-speed internet, you still should keep in mind slow connectivity while using HTML5. Even powerful web sites during peak activity are not able to timely serve overwhelming requests.

Finally, we’ve loaded the file. Wait, it says: “This audio format is not supported”…

Good bye plugins, welcome to codecs! The bitter truth is that with HTML5 you still be facing the horrors of browser/OS compatibility, the problem that plugins helped solve much. One might imagine that along with the “video” tag, the browsers would support a single standard video and audio format. No. Nobody in the world granted such a format for free. So you should use such syntax (taken from

<video width="320" height="240" controls="controls">   <source src="movie.mp4" type="video/mp4" />   <source src="movie.ogg" type="video/ogg" />   Your browser does not support the video tag. </video>

The <video> element allows multiple <source> elements. <source> elements can link to different video files. The browser will use the first recognized format.

Currently, there are 3 supported video formats for the <video> element: MP4, WebM, and Ogg:





Internet Explorer 9




Firefox 4.0




Google Chrome 6




Apple Safari 5




Opera 10.6




  • MP4 = MPEG 4 files with H264 video codec and AAC audio codec
  • WebM = WebM files with VP8 video codec and Vorbis audio codec
  • Ogg = Ogg files with Theora video codec and Vorbis audio codec

Speaking of the new tags support, this page is a good example of their way low recognition.

Lesson 2. As of now, HTML5 is a tool with poor support.


Easily Readable


War is Peace. Freedom Is Slavery.

George Orwell, Nineteen Eighty-Four


“[HTML5] core aims have been to improve the language with support for the latest multimedia while keeping it easily readable by humans and consistently understood by computers and devices” (HTML5)

The implementation speaks the opposite. Verboseness is the first sign of bad readability. For example, HTML5 still requires specifying image dimensions:

It is also a good idea to always include width and height attributes. If height and width are set, the space required for the video is reserved when the page is loaded. However, without these attributes, the browser does not know the size of the video, and cannot reserve the appropriate space to it. The effect will be that the page layout will change during loading (while the video loads).


Let me remind you how the browsers handle previously loaded resources: they send a request to the server, compare the modification date of the local and server copy, and if they match, the local resource is used. (NB! This is how it should work; do not expect such a behavior from the browsers all the time as they are “optimized”!) Along with the date stamp, the request could have fetched the dimensions of the video or picture; it’s almost the same operation… Expect that in HTML6, but now take your stone axe or another primitive tool, measure the resource, and hardcode the width and height! Do not forget to manually update those values after editing every resource! Advanced developers may offer image preloading or getting the measures via a separate AJAX call; it partially helps, but it still will be a patch for an expected browsers’ behavior.

Surprisingly, HTML5 still accepts short tags (like <tag />) (it also allows to omit the last slash, but for the sake of performance, please do not save on one character) and short attributes (like “checked” vs. XHTML’s “consistent” checked=”checked”). Luckily, we still can simply say <i> instead of “scientific” <span style=”font-style: italic”> and use <strong> although nobody knows what that tag is for.

As for the rest, HTML5 inherited and extended bad markup and XML practices, sacrificed simplicity for “academicity”, while some areas were just overlooked. Some examples:

-          You must provide an empty <title> tag even if you’d like to leave it empty.

-          Why <title> is still an XML element, not an attribute of <head>? For multiple or unsupported titles?

-          Old syntax align=”center” is deprecated and now should read margin: 0 auto; (not supported by IE, though. What’s the… fork? It’s text-align: center, where it might be applicable either to text only or to the entire content). Is that more readable?

-          New input types like <input type="email">. If HTML5 extended <div> to the new “semantic” tags like <article>, why not do the same for inputs? (Have <email> instead of <input type="email">.) So you still can use “checked” for images and “alt” for checkboxes although those “inputs” are completely different by nature. There are still many redundant input “types”.

Lesson 3. HTML5 is harder to code, read, and parse than its predecessor.


HTML5 Nuts.


The <frame> and <frameset> tags are not supported in HTML5, because they have a negative effect on the usability of a web page.

The <iframe> tag is supported in all major browsers.

The <footer> tag defines a footer for a document or section.


Stop talking, let’s code! My first page in HTML5 will be—guess what?—login. “Enter your name”… a text input… “Enter your password”… a password input… Hmm… the labels and inputs are not aligned… What? Set explicit width? Come on, my sites are always localized; in Chinese it will look ugly. In backward HTML4 I’d wrapped them into a table… What? Leave your div-s for your Bachelor’s degree work along with a good load of XHTML. I’m pretty sure HTML5 took care of such an obvious task…

Sorry guys, HTML5 has introduced anything related to the forms except what you’ll need every day. What I’d ideally expect for forms is something like that:

<VGroup caption=”Login” gap=”10” class=”…” >

<textarea label=“Enter your name”/>

<password label=“ Enter your password”/>


What such a notation features.

1.       <input type=”text”> and <textarea> are duplicates, and “rows” default value could be of 1.

2.       <input type=”password”> as I mentioned above is unnecessarily verbose (CSS notation is included) and simply <password> would be enough.

3.       <VGroup> is a self-explanatory tag, which determines alignment of its child controls; it might be used out of the form as well.

4.       The “label” attributes should be controlled by styles, and the parent <VGroup> recognizes them for mutual alignment.

5.       Finally, all the items are supposed to be properly aligned!

Now let’s look how it’s supposed to be in HTML5:



Enter your name: <input type="text" /><br />

Enter your password: <input type="password" /><br />



It features:

1.       <fieldset> -- misguiding name as one may try to use it out of the form. Some markup may not be a “field”.

2.       <legend> -- misguiding again, conventionally it’s an explanatory list of the symbols on a map or chart. Poor XML as “legend” deserves to be an attribute. Poor HTML as placing <legend> anywhere inside <fieldset> produces the same output.

3.       The labels and inputs are not mutually aligned!

You may also use the <label> tag:

<label for="female">Female</label> <input type="radio" name="sex" id="female" />

Notice the “for” attribute—the source for verboseness and heavy manual support. One may ask: why <label> is a separate tag? The answer is here:

The <label> element does not render as anything special for the user. However, it provides a usability improvement for mouse users, because if the user clicks on the text within the <label> element, it toggles the control.

Tip: A label can be bound to another element either by using the "for" attribute, or by placing the element inside the <label> element.

Got that? The <input> may be a child control of the <label>! But this is not the last idea, the <label> has also the “form” attribute, and a well-formed HTML5 code should look this way:

<form action="demo_form.asp" method="get" id="form1">   <input type="radio" name="sex" id="male" value="male" /><br />   <label for="female">Female</label>   <input type="radio" name="sex" id="female" value="female" />   <input type="submit" value="Submit" /> </form> <label for="male" form="form1">Male</label>

Quick explanation. You have a label far away from the input, and clicking the label toggles the referenced radio button.

Lesson 4. Forget MXML and popular JavaScript-based UI libraries; HTML5 makes you write excessive, non-elegant, and badly supported code. As for self-explanatory names, usability, and consistency, the HTML5 authors have their own vision on those subjects.




The decision to schedule the HTML5 Last Call for May 2011 was an important step in setting industry expectations. Today we take the next step, announcing 2014 as the target for Recommendation.

"W3C Confirms May 2011 for HTML5 Last Call, Targets 2014 for HTML5 Standard"


-          HTML5 is not a new technology, even not a next version of HTML that should have been released 10 years ago, but a draft specification to be hopefully finished in 2014. Support will follow.

-          Many features now are partially supported or not recognized at all.

-          Backward compatibility is <strong>-ly based on the dice methodology.

-          HTML5 allows to get rid of the plugins that worsens poor enough cross-browser support.

-          Standard UI controls and validations are only partially added. No asynchronous controls.

-          Added and not corrected misguiding tag names and the rules of their use.

-          More work for developers and browsers, less load for search engines.

-          Distinctive view on usability and consistency.


What should we do?


Some sections are already relatively stable and there are implementations that are already quite close to completion, and those features can be used today

WHAT Working Group, When will HTML5 be finished?


For a short-term development, especially if your site doesn’t require plugins, I’d recommend to not change the status quo. Why? Because your creation will not properly work for a significant segment of market. Do not be misled by the last statistics of entire browsers’ share as the most capable of paying customers set up their Internet Explorer 6 several years ago. Thus, the “old” way will cover the maximal number of users. With HTML5, you will not make your development easier as I tried to prove above.

If you’re still tempted by HTML5, try to use it only in lieu of plugins, mostly for multimedia and graphics. Prepare video converters to have differently formatted files for the variety of browsers, automate somehow updating the resources. Do not forget to create an update-your-browser-version page. Keep in mind that “old” users with previously purchased applications will get furious if the new browser version spoils their belongings.

For both approaches:

1.       Obtain a Rich UI JavaScript-based library like jQuery. HTML5 new controls are ridiculous (you’ll need active menus, data grids, etc.), and such a tool is a must. Yet, the libraries might offer HTML5-compatible sets, so it will not be your headache to timely fix discovered bugs. So with a UI library, your own code will be significantly independent of an HTML version.

2.       Do structure your code for reusing – as of now, the most popular programming pattern is CnP (copy and paste). HTML5 is unfinished, and a need for fixes and subsequent multiple replacements guarantees a nightmare for you and your users.

3.       Focus on usability—nowadays this is the key to make your site successful. (Almost nobody hires a usability specialist, and this role is assigned to the team members or—in the best case scenario—to the wife of the boss as she is closer to typical users and has a fresh eye.)

4.       To make #3 feasible, your site should be SEO-friendly. HTML5 easies this task, but standard SEO tricks are way effective.

5.       Browsers are using the same engine for rendering HTML4 and HTML5 so the performance will most probably be almost similar, excluding performance on some elements which are unique for HTML5.


Suggested reading.

HTML5 and The Future of the Web.



Thank you posting this

Thank you posting this helpful article about HTML 5. Good Job.