One of the disadvantages of writing a blog post on little sleep late at night in a hotel room while watching a movie and talking with Dion and doing your email is that you inevitably forget to write something you meant to.
In this case, one of the big drivers for writing the previous Bespin and Canvas post was to discuss accessibility–which I then neglected entirely to mention. Let me rectify that here and add a few other miscellaneous bits.
Rendering all of our content to a giant bitmap is obviously not the best way to integrate with all kinds of technologies designed to make content more accessible in various ways. But getting past that initial observation, we’re actually really interested in finding ways to make Bespin very accessible.
One of our initial ideas is to embed semantic content inside of the <canvas> element itself, as in:
<canvas> The content inside the Bespin editor could be embedded inside here as text nodes </canvas>
It might not be expensive (in UI latency terms) to keep these text nodes synchronized with the canvas editor since the UI thread doesn’t need to re-render anything as a result of the constant updates. If this approach were to incur a performance penalty, Bespin could have an “accessibility mode” that would optionally turn this on.
The Bespin dashboard also uses canvas, but for components instead of just text. We’re actually thinking of killing two birds with this one and having the hierarchy of the components defined inside of the <canvas> element:
<canvas> <splitPanel> <list/> <horizontalTree/> </splitPanel> </canvas>
We could then build the UI using this hierarchy rather than by using the entirely programmatic approach we have in place now:
// this is pseudo-code not pulled directly from Bespin, but // Bespin's dashboard code looks similar var splitPanel = new SplitPanel(); var list = new List(); var tree = new HorizontalTree(); splitPanel.add([ list, tree]); ...
You would style and layout these components using separate artifacts (CSS and a layout-specific artifact).
An advantage to this approach for accessibility is that we can provide a clean, fully-semantic hierarchy of the content, rather than status quo of HTML which runs the spectrum from style-and-content-mashed-together-seamlessly on one end to almost-pure-semantic-content-with-a-few-compromises-to-deal-with-CSS-realities on the other.
Let me again emphasize that Thunderhead is an experiment at what this kind of thing would look like; we’re not sure if we like it and we may scrap it entirely at some future point.
We’re frequently asked why we didn’t use SVG for the editor. To be honest, the biggest reason is that I have a lot of experience creating custom components with Java2D, and Java2D strongly resembles the canvas API. It was pretty natural to start hacking away with canvas and JS.
But there are a few reasons we felt good about going down that road to begin with. First, based on experimenting with DOM rendering, we felt we had good reason to suspect that SVG wouldn’t perform as quickly as the canvas implementation since SVG has its own DOM API and thus is likely to mirror all of the performance issues to be had with HTML’s DOM.
On top of that fundamental concern, we had another: while it’s straight-forward to implement our own painting optimizations in canvas (and we have), with SVG it’s much more subtle and involves understanding the implementation details of SVG run-times and whatever optimizations have been implemented under their covers (again, the same as with HTML DOM performance optimization).
Also, as a fairly large specification, we were concerned about compatibility headaches as differing subsets of SVG are implemented in the browsers that support it. We didn’t have the energy to fight DOM compatibility issues during the day and SVG compatibility headaches at night.
Having said that, we’d love to see an SVG version of the Bespin editor emerge at some point and compare its performance and codebases. There’s certainly a good chunk of JS code that could go away if an SVG version worked out.
We’ve also been asked whether we’d like to make it easy for folks to embed Bespin’s canvas editor in their own non-Bespin projects. Absolutely we do. Bespin will eventually spin out three projects:
- The Bespin project: an on-line code editor (i.e., the project we’ve currently announced)
- Thunderhead: a canvas/JS GUI toolkit
- (To Be Named Editor): a stand-alone canvas editor that you can embed
To make it seem less like I’m making this up just now, here’s what the Thunderhead logo looks like:
Canvas versus Firefox
However, we’re already talking with standards folks and browser folks about how best to pull some of these ideas back into the browsers. This isn’t canvas versus the browser, it’s about using canvas to experiment with new features ahead of the browser, and applying those “learnings” (is that really a word? WTF) back to the browsers.
More to come soon, thanks for reading.