HTML5 visualization readiness

Everyone’s been bashing Flash lately and holding HTML5 up on a pedestal. This circular graph thing, for example, shows what a combination of HTML5 and CSS3 can do and what features are available in major browsers. That’s great and all, but as you can see there are still a lot of holes.

The most glaringly obvious hole is Internet Explorer – which supports practically nothing. This is nothing new. Anyone who’s designed a site to work in all browsers knows this. But as much as you hate Internet Explorer, you’re not going to block content for some 80 percent of visitors, right?

On top of that, Flash provides richer interaction than HTML5 right now, and it’s going to be like that for a while. A lot of the work from the New York Times is in Flash. Stamen Design uses Flash. A lot of great work has come out of Flash – not just cruddy MySpace pages.

Now I’m not saying HTML5 isn’t going to be useful. It will be and is in some areas. But in terms of visualization, Flash is still better.


  • Peregrinator May 18, 2010 at 2:36 pm

    “But as much as you hate Internet Explorer, you’re not going to block content for some 80 percent of visitors, right?”

    What percentage of users are you blocking by requiring Flash for your visualizations though? We may wish Apple devices had Flash (or we may not) but that user base will continue to grow – are we going to prevent them from seeing our visualizations as well?

    Besides we’re quite willing to force the latest version of Flash on visitors despite the fact that if they are running IE6 they are probably on an older slower machine… The answer is rarely that simple :)

    If your visualization requires Flash use it, but we should begin thinking long and hard about what it is we need. The default shouldn’t be Flash. The default shouldn’t be HTML5/CSS.

    The default should be whatever produces the most understandable visualization using the least common denominator. In some cases that will be a simple image, no?

    • Good point! the audience is the king. But you should also take in consideration the development cost. We can’t all afford to spend time optimizing for various browsers. Flash gives you a good alternative to that. Would you prefer to give you target audience the best experience or everybody a half-ass one? Simple images may work well in many situations, but for rich data visualizations, you need a better tool.

      • Peregrinator May 18, 2010 at 3:01 pm

        Agreed audience is king.

        I would be careful in assuming that Flash means less development cost. Many of us already know ActionScript so that will play a part, but a great many of us also know html and javascript as well. Many of the fixes for IE browsers (e.g. lack of SVG) are easy and straight forward to implement in a large percentage of cases.

        One clear area Flash has the advantage is if you are placing large amounts of visualizations on a page (e.g. something like a lot of sparkline graphs). The lack of powerful JS engines in old browsers cause them to choke. But in situations like these we’ve found alternatives (like using Google Charts to generate sparkgraph images on the fly) to be the easiest and most compatible option.

        I’d be interested in hearing what from the features in the graph above are missing that you would consider essential for rich data visualizations.

    • @Peregrinator – 96% of browser users have flash already, so at worst you block 4% if you require flash…

      • Peregrinator May 19, 2010 at 5:45 pm

        @Rob My train of thought wasn’t that Flash isn’t pervasive (we all know it is), but that it is losing some of that ground and isn’t always the right choice and certainly shouldn’t be the default choice.

        Flash once was the default choice for me. I know ActionScript and I know Flex. But more often than not development costs would soar with Flash when we needed to come back to refine those visualizations. The problem was for many visualizations Flash is overkill. Visualizations are supposed to be as simple and informational as possible and much of that can be done with a more open tool that runs on just as many browsers in the intended audience.

        Just as an example – it has been reported that the iPhone accounts for 60% of global smartphone web traffic, and the iPod touch makes up more than 95% of all “Mobile Internet Device” traffic. And even on mobile platforms that support Flash you are getting the more limited Flash Lite that has less features and ability to deal with complex massive sets.

        We should be seeking ways to make our visualizations work in as many places as possible and choosing (and learning) the appropriate tools and techniques to do so.

        Flash is not gone, or even the wrong tool, but it’s not always the right tool either. And that goes for all of them.

  • I agree with you Nathan. Everybody is riding the HTML5 train and forget how long it took for the web to get more standardized. Even now, some of the browsers are still behaving differently, especially the IE family. From what I know, IE9 will still suck and that means we will have to live with this nightmare for many more years. Heck, there are still 8% of web users using IE6 according to w3schools, which tends to give higher statistics for standard browsers.

    The good news is that there are a few good JS frameworks available that work similar to Flash and are supported by most browsers. Raphaël is a good example that uses SVG standard to draw vector graphics in a very similar way to Flash.

    But I think it will take a few years for HTML5 development tools to catch up with what Flash is right now.

  • @baconner May 18, 2010 at 3:25 pm

    I don’t think many people are holding up html5 as a compete replacement for flash just yet especially not on the interactive data viz front. The point is viz developers who want to publish to the web will be better off if html5, particularly , is successful. An open option that benefits all vendors instead of one has greater potential to be ubiquitous and ubiquity is better for content developers.

    For highly customized and interactive viz flash is by far the easiest approach today. Fair point but what I’m hearing is not “hmtl5 is better than flash is today” but rather “we can do better and we will all be better off if we actively support new open options like html5.”

    Plus as has been pointed out the vast majority of basic charts can be done without a lot of trouble using various charting libraries. Even if ie9 holds off on canvas the new svg support will be an improvement in this area.

  • CaptainOblivious May 18, 2010 at 3:31 pm

    I don’t know how this chart is implemented, but it’s awful for at least two reasons:

    1) It’s terribly slow (FireFox 3.6.3 on Quad 3GHZ w/ 8 GB RAM) – if this is what HTML5 is like, I’ll stick with flash (which I despise with a passion).

    2) There no way to tell what each “ray” means without laboriously dragging the mouse over each one (and waiting for it up update)… 2001 called and they want their “mystery meat” navigation back!

    • It’s not slow for me, running FF 3.6.3 on a Core 2 Duo box with 4 GB which is not a powerhouse. Perhaps it’s your connection or the number of add-ons you have?

  • there’s other choices than flash vs html5+css3.
    first a lot of things can be done in plain html and css2, with or without javascript.
    then, there are tons of server-side scripts. that’s how the web started being interactive.
    and there’s java. java may have issues but portability is not one of them. and with java comes processing.
    now modern javascript libraries often rely on canvas, which is not supported by IE, but some offer the equivalent functions using SVG, in a way which is transparent for the developer.
    more recently, zingcharts released a library which can create charts either in modern HTML or in flash, depending on what the client can support.

    over 50% of my blog viewers are still using IE, so I’m stuck with IE-compatible visualizations. That’s one of the reasons why I use tableau so much, it works with everything from IE to iPhones.

    • Totally right. There are ton of options available. I just don’t think Flash needs to be kicked to the curb like a lot of uninformed people suggest.

      • I’m one of the creators of this infovizwhatever.

        This work has nothing didn’t mean to add to the HTML vs Flash debate at all. It’s only purpose is to give web developers an idea of how implemented individual features are, so that they can recognize @font-face has 100% support as well as contenteditable, etc. Most people interpreted it differently than its intent, so I’ll absorb that as one of its flaws.

        On the HTML vs Flash debate, the commenters above like Peregrinator and Vu Nguyen really nail it. Flash of course is nowhere near death and still has many many practical applications. I really enjoy which says “On each round there is a HTML5 and a Flash example that share the same topic. There is no winner, because you wouldn’t agree anyways.. ;-)”

      • @Paul – sorry, i wasn’t implying that you were uninformed. i was talking towards the people who take your page and say, “hey look, flash sucks” when obviously that’s not what you’re getting at.

  • For quantitative analysis, I would argue that you do not need flash to create a compelling interactive visualization. A prime case is Tableau Public that uses HTML, CSS, and Javascript.

    I would also argue that the chart “HTML5 & CSS3 Readiness” is a poor display for the data. In my opinion it is an example of visualization cargo cult, not unlike

    I agree with what Stephen Few has to say about these circular heat maps:

  • Matt McKeon May 18, 2010 at 9:40 pm

    Last year I would have agreed with you Nathan. In fact, somewhere I’m pretty sure there’s a tweet from me about how HTML5 just isn’t ready for prime time in infovis. There’s the IE issue, of course, and then there’s the runtime performance of the browser.

    I no longer believe that to be the case, for two reasons.

    First, the evidence I’ve seen is that more and more of our audience is willing to use a browser other than IE to view our work [1]. I’ve decided that I’m fine with providing graceful degradation to static images for IE users in a general audience. People may either use an alternate browser, or pull out their mobile device and look at the visualization there.

    The NYT and Stamen, in my opinion, are operating under different constraints than the average visualization creator. They’re dealing with megaperson-scale audiences, and have a lot of money riding on even %1 of their visitors. It’s worth it to them to make the necessary tradeoffs (in lack of mobile support, and [IMO] user experience) in order to harness that last bit of audience.

    Second, cross-platform toolkits for HTML5 are there and working (mostly) well. I’m not generally impressed with Raphael’s capabilities, but dojo’s gfx API and Processing.js are fairly easy to use and give me the features I need (particularly SVG font support).

    Performance, though, is still a problem. Firefox dominates the non-IE browser space and its current Javascript engine simply can’t handle reasonably complex animation at an acceptable framerate. Safari on the iPhone is still a lot slower than any browser on a laptop. So currently, if you target HTML5, that means you need to give up some dynamism *or* do browser/device detection and degrade the experience gracefully depending on the platform. But that is at worst a temporary condition.

    I’m fine with Flash, and will continue to work with it as the circumstances require. However, I believe we’ve already arrived at the tipping point, where HTML5 is finally a viable platform for mass-audience infovis.

    [1] Two possibly relevant datapoints: that Facebook privacy vis I posted last week has gotten quite a lot of unique visitors, and only 14% of them were on IE. By comparison, Many Eyes (which is all Java/Flash) consistently comes in around %30-33 IE. Significant, but nowhere near %80 or even Jerome’s %50.

    • @Matt – For sure. I don’t remember the last time I saw a computer that didn’t have Firefox installed on it. Personally though, I don’t want people to have to switch browsers to see something I do, no matter how much I want even more to tell people to stop using IE. I want it to be one unified experience e.g. when a graphic is coupled with an article.

      On [1], I don’t know why I said 80%. That’s way bloated. It’s more like 60%. I wonder though if your 14% says more about the type of people who like to look at standalone graphics or the sites that pointed to your Facebook privacy vis. For example, only 14% of FD visitors use IE.

  • adamredwoods May 18, 2010 at 11:32 pm

    Flash vs HTML: Designers create, clients pay– but clients don’t care about the underlying technology, only the end, visual result.

    There is no winner to the Flash vs HTML5 debate unless you get paid by the hour.

  • Shouldn’t we also point out that this chart is full on junk? I am forced to roll my mouse over each spoke (bar?) in order to see its category. Gimme the underlying data, I’ll do an equivalent in Tableau that’ll be much easier to read.

    Oh, what’s that? It won’t be very bling. Maybe, but the info will be easier to digest.


    • Linus Schultz May 19, 2010 at 4:49 pm

      Oh my goodness, I couldn’t agree more.

      What is it with the general public and their phobia of graphs? It’s come to the point where showing a bar chart will scare away so many people, they have to spiffy it up and make it look like a flower or a sunrise before people will look at it.

      I came to that conclusion just by looking at the image at the top of this thread, which means I hadn’t even seen that most of the information was missing until you moused over it, or that the slices were “dropped down” instead of having each browser’s color float at the appropriate height (as they do in the image).

      This graph is a posterchild for artistically pleasing but poorly thought-out graphs everywhere.

  • This starburst graphic is very attractive, and horribly ineffective.

    What’s wrong with a table of rows and columns, one row per feature, one column per browser, with the grid consisting of either a check for a feature present in a browser or a blank for a missing feature. Everything is visible from start to finish.

    I mean, besides the lack of gratuitous rotational symmetry, interaction, and color.

  • Oh Jon, you’re so 20th century

    BTW – Stephen Few’s latest newsletter nicely summarises the problems with circular visualisations:

  • Throwing in my 2 cents…

    We are porting an institutional stress testing infovis from Processing, into Processing.JS, then using the canvas import in Silverlight. Pretty easy actually. Although I made my mark in the world with Flash in the late 90s, on this end of the market, it is all Java and Microsoft IDE. Adobe has a pretty solid UI stack, but, they are back filling it with a framework.

    If you have the time, you can see what the next versions of IE will be like by testing the Microsoft Pivot Beta. It’s a stomping ground for exploring features.

    This argument is a little silly to me. If you are doing enterprise infovis, where you are targeting and specing on hardware, the important thing is starting off with something like OpenFrameworks or Processing. That way, moving across platforms is easier. You should be able to build applications in whatever technology stack is required. Each has its benefits and drawbacks.

    In the consumer space, its an infovis we are talking about right? There is no barrier to using Flash, in fact, it would be pretty stupid not to use it. Lots of developers, plugins on every machines, user expects they are going to have to load something. Plus, its takes a few seconds to change any physics code we have done in Actionscript into C#.

    Please post a solid review :)

  • This topic hits very (very…) close to home. I build complex, highly interactive infovis stuff for an internal application. Years ago, we started using touch tablets for this stuff – so when the iPad came out, it was an obvious upgrade. Except that it doesn’t work for us since everything we’ve done has been in Flash.

    I’m 100% ready to switch to HTML5/CSS/JS (I have no attachment to flash) but those languages are quite simply the wrong tool for the job.

    Let’s just take one simple example:
    Google finance charts:

    I’ve “built” this in HTML5/etc and… good luck. It’s a battle to get anything close – it basically doesn’t work. (Particularly, the really nice slider/time selector at the bottom, and the very reactive mouse-overs.) There are just too many barriers. (outlandish even: ever try to render text – e.g. a mouseover – in a Canvas element….?)

    There’s no question that HTML5/etc is completely the wrong tool for that job (further, drop that on an iPad, and when you drag the slider left/right, the PAGE moves left right… HTML5 is definitely not ready for touch).

    I’m not suggesting that the google chart *can’t* be done in HTML5/etc, but I do believe it’s the wrong tool for the job.

    At the moment, Flash is the right tool for the job. In Flex, I can recreate that google chart in about half a day from scratch. No extra libraries, no browser specific code.

    So, bottom line – I agree – the whole “throw out flash” argument is silly and premature. If we need to replace flash (because Jobs says so), then we need a viable alternative…

  • Peregrinator May 19, 2010 at 1:11 pm

    Thought I’d throw this in as it seems pertinent to the discussion… discuss :)

    From Google IO Conf:

  • Great discussion so far and one that also hits close to home for me too, being on a team that develops datavis tools. [I’m on the ZingChart team that Jerome mentioned].

    I wanted to bring up a point about Flash vs. HTML5 performance, as that’s the next step once you get a chart to *work*.. and some of the comments above mention the issues surrounding cross-browser compatibility and speed with HTML5. We’ve been gathering data on platform/browser/chart type using a side-by-side speed test (, and will be charting the data soon. I’d be glad to share the data as well if anybody would like to play around and visualize it.

    Here’s an interesting preliminary observation we’re noticing in the results:

    There is no unanimous winner. Even on the same browser and computer, graph complexity affects the outcomes. For instance, HTML5 is considerably faster on simpler charts and when there are smaller datasets. As data becomes larger (into the thousands), and/or as shadows, gradients, and more graphical elements are added, HTML5 performance diminishes significantly, whereas Flash remains very fast.

    I’ll be interested to see which direction this goes and how fast. After Google IO day 1 it looks like there’s a ton of power behind HTML5, but Nathan called it: Flash isn’t getting “kicked to the curb” like the pulse of the internet may suggest.

    • Peregrinator May 19, 2010 at 6:01 pm

      Interesting stuff Andrew!

      It’s seems that the Flash rendering time is much more consistent (probably due to the fact that it is compiled) than the Canvas equivalent. I imagine the variation in Canvas load time has a lot to do with what else the browser is doing at the moment.

      A couple questions though. Is the js library you’re using for the canvas graph been optimized (especially for large data sets). Also it appears that the canvas element in the ‘3 series x 1000 data points bar chart’ comparison has transparency turned on and the Flash side does not. Also the canvas doesn’t appear to be interactive in that example.

      When you have massive data presented in the final example (3 series x 1000 data points) do you find that the interactivity shown actually helps comprehension?

      • @Peregrinator absolutely correct about the browser stress for Canvas…

        We’re actually not using jQuery or another library; we’re acting on raw JSON and using direct DOM and Canvas calls. (jQuery and others had nontrivial overhead that hurt Canvas results)

        The appearance of transparency is actually due to the differences in the way Flash and Canvas render graphics (especially when plotting extremes like 1,000 bars in a 350 pixel-wide area). In this test, we wanted to see render times with the same datapoints/settings rather than adjust to the inherent rendering differences between the frameworks.

        Not sure what you mean by the interactivity differences on the 3×1000 bar chart. Can you specify? Either way, adding interactivity in the form of animation, tooltips, or otherwise does have a significantly larger effect on Canvas than on Flash. The goal is/was to have the same features and datapoints on each of the side-by-sides.

        Last: while we’re pretty well-read on Tufte, Few and other relevant datavis authorities, we try not to be biased for or against interactivity, chartjunk and the rest when it comes to comprehension — we try to provide enough colors and brushes to make a masterpiece or a mess depending on the painter :). We are trying to provide some good examples and how-to’s on our blog to help bridge the gap between great designers and great developers.

        I will say that the *appropriate* use of tooltips, rules, guides and other interactive elements helps walk the line between Tufte-esque simplicity and overdone chartjunk. See the chart gallery on our homepage for a pretty wide range.

        For further reading, check out this informative article called GUIMark 2: The rise of HTML5: (great rundown of JavaScript vs Flash rendering performance for charting, gaming, text, mobile, etc.)

  • I love flash stuff ( I remember there in 2002 looking astonished that incredible code in )
    That said, I think HTML5 / CSS3 / JS will be my choice if I had to teach web design to new people. HTML5 It’s open, and It’s a standard, and there are lots of examples of its great performance. Check cloudz project ( ) in Chrome, an interactive visualization of delicious feeds.