Monday, October 12th, 2009

Crazy Times: Rendering HTML…. in Canvas

Category: Canvas, HTML

It’s still early work but James Urquhart has gotten HTML rendering inside the Canvas tag. In his demo, he renders the following HTML into the Canvas element:

  1. <html>
  2.   <head>
  3.     <title></title>
  4.   </head>
  5.   <body>
  6.     <p class="woo" id="render" style="display:none;">
  7.       Rendering <b>HTML</b>...
  8.     </p>
  9.     <p><span>In <b>Canvas</b></span>!</p>
  10.     <p>0_0</p>
  11.   </body>
  12. </html>

It’s still pretty simple, but this renders as:


Much of the real work involves regular expressions plus using the Canvas measureText and fillText functions. Right now he is parsing the following tags: HTML, BODY, P, B, and SPAN.

Run the demo yourself (FF 3.5+ and Webkit based browsers only). All the code is open source and available on GitHub.

James jokes that we might one day see HTML Canvas running in HTML Canvas running in HTML Canvas…. turtles all the way down.


Posted by Brad Neuberg at 6:30 am

2.6 rating from 39 votes


Comments feed TrackBack URI

You’re seeing a tiny glimpse of the future here folks: the web development stack done right! Canvas + JavaScript = HTML, CSS, SVG, …

Comment by philmaker — October 12, 2009

so a new era has come. html render engine wars in canvas. “so does this bug affect canvas in gecko or canvas in webkit or both?” How meta.

Comment by andriijas — October 12, 2009

Right, I wish good luck when he needs to implement CSS level 1 and 2 and 3 in this Canvas implementation.

What a waste of time.

Comment by Jeria — October 12, 2009

I can see this as a useful exercise to become familiar with Canvas, but otherwise, why?

Comment by sos — October 12, 2009

I think this is a ridiculous notion, but hints at something that is more worthwhile in exploring. In most non-web gui systems, the rendering stack is build up with layers of abstraction, starting from the lowest level paint operations, and building UP to controls, layout managers etc. HTML takes the opposite approach. You can’t override the paint method of a button or a div. Your lowest level is already high level – html/css. On top of that is something with arbitrary rendering ability, canvas.

In general, the way to do this right would be to open up the rendering pipeline a little more to allow canvas style paint operations in arbitrary regions of the DOM (which is basically just a 2d scene graph). HTML could still sit on top of it, but for those willing to go deeper, they could. And then you would have to try for any of these shenanigans.

Comment by genericallyloud — October 12, 2009


Comment by genericallyloud — October 12, 2009

@genericallyloud: I like your idea. If I got it right it will make us able to paint inside input type=”submit” objects and all sort of things.

Comment by pmontrasio — October 12, 2009

Mozilla Bespin is a Canvas based editor, and uses a lot of formatting on the text. May be interesting to see how that works.

Comment by Poetro — October 12, 2009

One huge problem with canvas is the lack of accessibility. I mean if things is drawn in a canvas then it’s like a black box for a screen reader. So interfaces like Bespin is not accessible. This is a bummer since we could make lots of cool apps using canvas. Like drawing your the whole application UI your self instead of using HTML/CSS.

Comment by Spocke — October 12, 2009

@spoke: ARIA is a W3C specification for making Ajax applications accessible. There is some debate on how to extend it to canvas and svg.

I think it is acceptable that some applications are not accessible by design. Most videogames are not and they couldn’t be made different. Examples: FPS, car racing games, basically everything that moves quickly.

On the other side most information that we can draw into a canvas (example: charts) can also be shown as text in the same page and this is the common approach now with charts (think about google analytics). Overall I’m not greatly concerned about canvas unless it’s abused. It’s no different than any other W3C technology.

Comment by pmontrasio — October 12, 2009

They’ve been doing this sort of thing in flash for a while now:

Comment by Joeri — October 12, 2009

I’ll go ahead and ask this question again:

How long until when you serve up your web pages you also serve up the rendering engine along with it?

Then you’d be sure your page would render exactly the same everywhere.

With caching, compression, virtualization, a good sandboxed security model, etc. this doesn’t seem impossible or implausible at all.

Comment by zachstronaut — October 12, 2009

it’s an html2Img() converter, calling it anything more luxurious than this name is trouble.

Comment by jaysmith — October 12, 2009

@zachstronaut: I’m with you on that point.

It’s about giving the appropriate groups the appropriate mandates; users should chose a browser according to what user-centric features (tabs, webclips, whatnot…) it has that makes sense to them – and web developers should decide what rendering solution should be use to show their pages.

This, of course, is not the case as is. Users are unaware of specs, acid-tests etc and therefore do not/cannot “vote” accordingly; they decide (or passively refrain from deciding) what browser is installed on their system. The matter is out of our hands.

I’ve always felt something missing from the specs: actual working implementations of the specs. Ones that could be scrutinized to gain insight into how the specs where to be interpreted when vague or in edge cases. I mean just look at the discrepancies between browsers up till now (yes, it has become alot better, but still). We should’ve learnt by now that continously reinventing the deep dish is a waste of time…

Seperating the browser shells (tabs, webclips…) from the rendering engines would be a sane way to go. And Google has already shown us a glimpse of this (if hacky) through Chrome Frame!

Oh well, one can dream. ;)

Comment by rasmusfl0e — October 12, 2009

… and for the sake of being on topic; implementing html rendering in canvas is an interesting thought – but instead of implemeting an existing layout spec I would much rather pursue making an improved layout spec. I’ve never understood the reasoning behind block elements having full width but no height at default (and not be able to inherit the heigth of its parent!). I would want to experiment with an alternate layout scheme for sure!

Having seperate rendering engines would accelerate the spread of such improvements. But it would be impossible as things are now – layout specs are practically set in stone.

Comment by rasmusfl0e — October 12, 2009

@rasmusfl0e Yes, just like you said! Let the end user pick their GUI… how tabs and search work. Bookmarks. etc. etc. Let the content provider decide how the rendering works. I’m glad I’m not alone in this line of thought.

But I really do not want to go the Flash or Java route with this either. One could serve up a Flash or Java app instead of a web page and have fine tuned control of rendering now. But the biggest problem there is that so much of the browser/OS GUI suddenly breaks down when you are dealing with the Flash or Java app. Suddenly you can’t bookmark or you can’t copy/paste or you can’t do a user css style sheet etc. etc. I don’t think serving up proprietary executables is the way to go. I’m talking about something where we are still serving up some sort of XML which could be interpreted by many potential renderers… but the content provider can supply the default renderer.

Comment by zachstronaut — October 13, 2009

Aww, I was hoping that this would be an actual rendering engine, rather then an image snapshot creator for three or four elements, I mean come on you can do better =/

I could throw together something like this that at least includes at least textarea, buttons, and images over the weekend, but why? Is there really any use for a barely working HTML renderer?

A XUL renderer, now that might be something I would like to get into because XUL is a format that doesn’t have a native rendering engine in Firefox and Safari.

Comment by jhuni — October 13, 2009

Something is deeply wrong with web-development…

Comment by jayarjo — October 20, 2009

Re: Something is deeply wrong with web-development…

Keep hope alive:

Comment by philmaker — October 20, 2009

Better starting point for Lively:

Comment by philmaker — October 20, 2009

Leave a comment

You must be logged in to post a comment.