Bark of the byte

Running with bytes and other wild creatures

Can the HTML5 Canvas save us from cross-browser woe?

Anyone who has developed even the simplest web page will be familiar with the following steps: -

  1. “Har har, my page looks great!”
  2. “Hmm, not quite right on this browser”.
  3. **tweaking**
  4. “Ah, that’s better.”
  5. “Hmm, that broke it for this browser.”
  6. Go to step 3.

There are many variations on that theme. Often these differences are subtle and require a deep knowledge of the specification and the nuances of the offending browser to finally hack in some code that works across browsers or degrades gracefully for the incapable. 

My latest nasty surprise was when I was doing some javascript transforms and found that IE (sorry IE) forgot to implement preserve-3d.  From MSDN:

“Note  The W3C specification defines a keyword value of preserve-3d for this property .... At this time, Internet Explorer 10 does not support the preserve-3d keyword. You can work around this by ...”


For the rest of this post, I am going to look at some possible solutions for this wicked woe.

If only they all followed the specification (dammit)

All hail the spec. If they all followed it we would be fine. Well, things have improved since a particularly errant browser (not saying who) has finally come into line and started following the HTML specification. However there are a few problems with multiple products all following a large software specification: -

  1. The spec can be interpreted differently. The specification is in natural language (as it should be) and there can be minor implementation details that are omitted or ambiguous. You don’t have to look far to find instances where browser implementations were following the specification, but implemented things slightly differently. See here for an example.
  2. Browser progress often out-paces the specification or partially implements it. In their enthusiasm to bring us the latest greatest features, browsers implement features that are not fully specified, are still experimental or are specific to their platform. This, I think is one of the messiest parts of web development: –webkit, –moz, –o, –ms. What a disaster for DRY.

The HTML 5 Canvas

One solution is to drastically reduce the scope of the native browser elements that we use. What if the only element that the browsers had to implement in a consistent manner was the HTML 5 Canvas? I think that even some of the least conformant browsers should be able to handle that. This would dramatically reduce the scope of change that can creep in between the browser implementations. 

The idea is that 3rd party developers can create frameworks or libraries implementing the standard controls (text boxes, labels, buttons, etc) that web developers could use. They would start out with the base user controls and grow from there.

All that we as developers would need to do is choose an appropriate framework. Some frameworks would rise to fame and popularity and eventually we would all be putting our experience with “The Framework of Magick Widgeets and Drawningnesses” on our profile pages. The key point is that since the HTML 5 Canvas is standard across all browsers your UI would look the same on all. Of course, there may be differences in implementations of the HTML 5 canvas, but the scope for delinquent browser implementations is dramatically reduced. Developers could choose whatever framework they wanted, it wouldn’t matter. The framework could be downloaded on demand or the browsers might come with some of the more popular frameworks pre-packaged.

What is the catch?

The HTML5 specification advises against implementing edit controls in the canvas. There are a number of reasons listed on this W3C page (search for “20 Best Practices”) for not implementing controls in the canvas. I won’t list all the reasons mentioned on the page, but the gist is that a whole lot of things need to be re-implemented. While I agree that those are good reasons for me not to implement edit controls in my own project, if it was implemented in a framework then it only has to be done once and we all benefit. It may be hard and a lot of work, but we tend to be good at that. Shifting sands and lack of control we are not so good at.

Isn’t this the same as flash? There are similarities, except that the canvas is a first-class HTML 5 drawing element, where as flash was a heavyweight plug-in.  

They might not like it. We all recall that some vendors famously chose to keep flash out of their devices. The reason given was that it was not open and future-forward enough. I guess this would be the real test of whether that was the case or if they were just protecting their own app-stores (as per the grumblings at the time). If you are looking for conspiracies this seems to be the best reason why web development feels like making rockets out of sticks, clay and firecrackers while app development is like the Kerbal Space Program.

There are already some frameworks available

Maybe this is already happening under our noses. A quick search show up these existing libraries (none of which I have tried): -

What do you think?

Could a set of sleak HTML 5 Canvas frameworks that allow us to build web UIs seamlessly across browsers be a solution? 

Loading