Monday, October 12th, 2009
Crazy Times: Rendering HTML…. in Canvas
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:
HTML:
-
<html>
-
<head>
-
<title></title>
-
</head>
-
<body>
-
<p class="woo" id="render" style="display:none;">
-
Rendering <b>HTML</b>...
-
</p>
-
<p><span>In <b>Canvas</b></span>!</p>
-
<p>0_0</p>
-
</body>
-
</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.
2.4 rating from 32 votes
You’re seeing a tiny glimpse of the future here folks: the web development stack done right! Canvas + JavaScript = HTML, CSS, SVG, …
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.
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.
I can see this as a useful exercise to become familiar with Canvas, but otherwise, why?
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.
*wouldn’t
@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.
Mozilla Bespin is a Canvas based editor, and uses a lot of formatting on the text. May be interesting to see how that works.
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.
@spoke: ARIA is a W3C specification for making Ajax applications accessible. There is some debate on how to extend it to canvas and svg. http://www.google.com/search?q=canvas+aria+accessibility
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.
They’ve been doing this sort of thing in flash for a while now:
http://motionandcolor.com/
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.
it’s an html2Img() converter, calling it anything more luxurious than this name is trouble.
@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. ;)
… 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.
@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.
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.
Something is deeply wrong with web-development…
Re: Something is deeply wrong with web-development…
Keep hope alive:
http://livelykernel.sunlabs.com/
http://livelykernel.sunlabs.com/repository/lively-wiki/index.xhtml
http://research.sun.com/projects/dashboard.php?id=176
Mirror:
http://www.lively-kernel.org/
http://www.lively-kernel.org/repository/lively-wiki/index.xhtml
Better starting point for Lively:
http://research.sun.com/projects/lively/
GH337, as a digital mobile phone, empire wedding dresseswhether it is performance or other aspects are much better than the analog phones could also say that empire waist wedding dresseswas the fashion trend.Ericsson T68: the first color screen mobile phone Ericsson T68 was launched in the finalstrappless empire waist wedding dresses of a cell phone, but also a location in the high-end mobile phones, evening formal dressesit is the emergence of the mobile phone world has become Behind colorful.Ericsson GH398: Custom ring tones plus size evening dressescan be the first mobile phone Ericsson has brought unconventional way this could be composing cheap flower girl dresses ringtones GH398,Unfortunately, mobilephones have not yet popular in that era, which ended in failure.Ericsson T39mc: wedding dressthe first built-in Bluetooth-enabled mobile phone August 2001 Ericsson released the world’s first built-in Bluetooth chip for mobile phones T39mc,Empire Halter Satin WeddingDresswhich is Ericsson’s first tri-band GSM and GPRS high-speed Internet-ready phones.Ericsson R250 PRO: the first three anti-cell phonewedding dressR250 PRO is the first with a waterproof,Empire Halter Chiffon Wedding Dress shockproof, dust-proof function of the “three defenses” outdoor-type mobile phone. It is in the third quarter of 1999 to the market.
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.It’s no different than any other W3C technology.
Infant Baby Bedding