Posts Tagged ‘html 5’
  • HTML5, still a non-event?

    A little less than 4 years ago, I wrote link:{% post_url 2008-06-21-html-5-a-non-event %}[an article^] entitled "HTML 5: a non-event". That was before the HTML5 umbrella move grouping HTML 5, CSS 3, WebSockets, etc. and before the HTML5 logo. At that time, there was a buzz around HTML 5 coming to save developers from pesky HTML 4 limitations. At the end of the article, I was doubtful of the real value of HTML 5 in the short-term and predicted the coming of the final specification 2 years after (2010) at best.

    Here we are, 4 years later and the (sore) state of HTML 5 has not changed much.

    What still applies

    HTML 5 is still a Working Draft

    HTML 5 and all its related technologies are technical standards hold by the World Wide Web Consortium. The organization has organized its specifications into 4 logical and consecutive lifecycle steps:

    1.Working Draft (WD). Citing the W3C documentation regarding its specification processes:

    A Working Draft is a document that W3C has published for review by the community, including W3C Members, the public, and other technical organizations. Some, but not all, Working Drafts are meant to advance to Recommendation;[…​]

    1. Candidate Recommendation (CR)
    2. Proposed Recommendation (PR)
    3. W3C Recommendation (REC)

    If you read between the line, the WD is basically a work in progress, meaning it can change drastically between versions. Guess what? The specification is still a WD after all those years and the last update date reads 25 May 2011. Granted, they have worked on it since my previous article but nothing was released as a specification.


    • To be entirely honest, an editor’s draft version is much more recent (7 March 2012) but I couldn’t find anywhere the status of an Editor’s draft regarding the above document lifecycle.
    • When browsing through the specification itself, a big message warns about it being a work in progress.

    Editors are building on sand

    This point is the logical conclusion of the previous one. Google, Adobe, Mozilla and others are implementing features that are by definition not set: they’re basically investing time and resources on sand.

    Granted, it’s highly unlikely a major change would take place, but then why not advance the specification maturity then to send a clear message to the community? The state of things only increases the probability of an editor walking its own path.

    Heterogeneous features

    You thought cross-browser compatibility was hard with HTML 4, CSS 2 and JavaScript? HTML5 brings the concept to a whole new level: for fun, check this site for a list of all features and the select the desired feature. Come back when you’re done weeping.

    The good people at Modernizr thought (rather cleverly) there was something to address: how could we developers adapt to each and every browser and degrade gracefully? The library let us test for a feature and see whether it’s available. Even more importantly, some libraries are available to backport unsupported features with the help a magic JS script. The plumbing implementation is left to you. Good luck, JavaScript ninjas!

    Heterogeneous implementations

    Whereas heterogenous features are a part of HTML since its inception - the complexity in HTML5 coming from the numerous features, we relied on the same implementation thoughout browsers. Now, a single example being more vocal than words, how can we developers ensure a rounded corners display in CSS3 today? The answer makes my heart sink:

    .rounded {
      -moz-border-radius: 10px;    /* Firefox */
      -webkit-border-radius: 10px; /* Webkit usd in Safari and Chrome */
      border-radius: 10px;         /* True CSS3 */

    Who may call that progress?

    We’re definitely not in Fairyland

    This article finds in origin in a high-level presentation on HTML5 where the speaker cluttered its talk with "it’s simple" and sold dreams to the audience. Please, we’re working in real-life, not in conceptual PowerPoints. I’m no plumber but I think I’m fairly capable of drawing a plumbing diagram. Woe to the poor plumber that has to realize it in reality, however.

    Don’t take all HTML5 examples on the web at face value, they’re prototypes (even if they work on your modern browser). If you’re curious, look at the sources: is it really so simple? Does it degrade gracefully?

    Buzz, buzz, buzz and some more buzz

    Technical people are generally poor marketers. In the case of HTML5, there’s a whole site dedicated to promoting HTML5. If there was a solid specification beyond this, I would be an ardent supporter of "the project which can communicate". With all the previous points raised, I’m asking myself whether the time and money should have better been spent on foundation rather than decorum.

    Miscellaneous, but severe

    Ever heard of Slideshare migrating from Flash to HTML5? At the time of the announcement, I checked and found that fonts shown in large size were not anti-aliased. The presentations were unreadable since they were so ugly you could not focus on content. It seems they have corrected the problem by now, but some presentations still look slightly worse than their Flash predecessors.

    During the writing of this article, I also found some other implementation failings regarding CSS property values. I’m sure there’re plenty more available for those looking for them.

    And still…​

    Despite all these black points, there are definitely some advancements toward achieving HTML5.

    Some editors let go of their proprietary products to walk the HTML5 path: Adobe gave Flex to the Apache Foundation (which some understood, including me, as something akin to a murder in cold blood) and Microsoft redirected Silverlight’s underlying technology to HTML5. More editors coming to HTML5 mean more momentum and more drive. For fairness’s sake, it also means more petty interests to take into account…​ Clouds and their silver linings reversed.


    IMHO, the root of all Evil definitely is the maturity level of the specification. When the specification is released in a consecutive level, there will be browsers that follow it (in part or globally) and browsers that won’t. End-users and developers will then be able to choose which browsers to support, according to their respective strategy: in the zeigeist, I’m relatively confident standards-following browsers will emerge as winners.

    Currently, HTML5 is a dream, surely a beautiful dream, but a dream nonetheless.

    Categories: Technical Tags: html 5
  • HTML 5: a non-event

    Since the beginning of the Internet, it is here.  What? The HyperText Markup Language, of course. Thanks to it, we can now navigate across the web with hyperlinks, watch images and videos, download files!

    It was not always the case. HTML has several incarnations, each enabling the next. For example, did you know that before Mosaic, the <img> tag was unknown? No images then…​

    Now, the W3C, responsible for the HTML standard, is currently drafting the new HTML 5. What’s in it anyway?

    • New elements. And since you’re now in the semantic web (more later), they have meaning: <nav>; for a navigation bar, <footer> for a footer (how original), <audio> and <video> for media elements, …​
    • Dropped elements. Yes, <font> and <center>, for example, were purely presentational tags. As such, they should have been banned a long time ago in favor of CSS (still more later),
    • New form elements. How many times did you curse the business analyst who wanted a field that could contain an email and who provided you with a zillion business rules to check the email validity? If the browser is now smart enough, it could validate the input for you,
    • An API that should handle offline-status, drag-and-drop, persistent storage and much more: the best part of this spec I think.

    Wow, sounds exciting. And yet…​ Remember three or fours years ago? Everybody was talking about the semantic web. The semantic web was the buzzword at this time. It was (and still is) a nice idea. It means that tags should carry meaning and not presentational informations. This last part should be the reserved domain of Cascading Style Sheets (CSS).

    For example, in the semantic web, you should not use the <i> (for italic) tag but rather the <em> tag to indicate that the tagged part is emphazised. Both would render the same by default anyway:



    After reading this post, I just realized my CSS showed these in bold. It just proves my point since what should be italic is rendered in bold.

    Why should you do that, by the way? The <b> (for bold) equivalent is <strong> and is much longer to type. Because of the semantic web. Because you want to carry meaning. But more importantly, to let your page be parsed by robots: they can then isolate the <author> tag and attach your name to their database (it is only an example).

    Well, at the time, every developer, even junior, fresh from school, would display their personal web page, show you it was HTML 4 compatible and tell proudly it was 100% semantic. Today, I don’t even hear the word. I’m an application developer, not a web developer, but I think the term is gone. According to me, it is because people don’t care about being put into a database. They care about being seen, that’s for sure, but that stops there. Google, Yahoo and peers care of course, but what can they do?

    As for myself, I’m an ardent supporter of semantic tags so that I can present my page the exact way I want with CSS (this depends of course of the browser but I’m an optimist). Yet, when in the rush of a project, you can’t always be a perfectionist. You put a <b> tag here, a <style> tag there, it takes only a couple of seconds and your customer is happy.

    Gone is the semantic web and nobody cares! Why so? Because HTML is gone too. Before anyone noticing…​ Because application are everywhere and everybody wants to develop them: blogs are a perfect example of this. HTML was not thought to support applications. These frameworks are:

    • Adobe Air,
    • Mozilla XUL,
    • Laszlo for the OpenSource JEE world,
    • JavaFX for Sun Java,
    • Eclipse RIA,
    • Silverlight for Microsoft,
    • and many more yet to come…​

    They are Rich Internet Applications (RIA) frameworks. They are fast but more importantly they are beautiful and they have the ergonomy of real (understand fat) applications. They don’t think in term of pages but in term of view.

    So, the current draft seems at least to understand the drawbacks of HTML 4 regarding applications development but much, much to late. And in the pure web development part, it amounts to next to nothing. The coming of the final spec (in 2 years at last) is thus a non-event.

    Categories: Technical Tags: drafthtml 5specw3c