HTML5 - What direction should we take?

I've been spending my time, lately, working on an Android port of The Render Engine to allow developers to create games in JavaScript, yet be able to take advantage of the platform in a native way.  While working on this approach, I've also been thinking about the best way to market the engine.  It seems that a lot of people have a preconceived notion in their heads about what, exactly, makes a game an "HTML5" game.

The feeling I get is that most people think "tile based game rendered in the DOM" when they imagine an HTML5 game.  However, it goes so much further than that... With the advent of the Canvas, people have been trying (myself included) to utilize it much the same way as developers did for games when EGA and then VGA showed up on the PC.  Rather than textual characters and lengthy text descriptions which made up a lot of games, the game players were wanting more so they invested time in learning how to access the graphics, directly.  This doesn't necessarily mean  that games written to use the DOM as their rendering "context" are bad.  But it can be limiting when trying to do advanced effects.

I don't want people to think that The Render Engine is solely a Canvas-based game engine.  It still supports the DOM, and it can do so with very little difference when writing a game for Canvas.  This allows developers, to make a choice when writing their game, to choose what their target audience is.  The way the Canvas works is similar to the way modern games are written for the PC, Xbox, Wii, or other gaming platform.  You render all of your content to a buffer which is then displayed to the player a frame at a time.

When writing a DOM-based game, however, it isn't the same.  The DOM is always live which means that a change to the DOM happens immediately.  There isn't the "clear and redraw" that occurs for "typical" games.  If the standard method of drawing a frame using CanvasContext were applied to HTMLDivContext, the engine would end up creating thousands of objects in the DOM.  Instead, the engine uses the DOM-created object as a mini-canvas (if you will) which is updated, as needed, to run animations and draw the world.  Ideally you wouldn't have to know about this and the engine would take care of all of that for you, but this isn't the case.

To truly make a game run in every browser, you have to design for the least common denominator.  In this case, that would be the DOM since IE (at least until IE9) doesn't support the Canvas.  While the engine tries to alleviate some of the work from the developer, not all of it will work as expected.  As such, a developer writing a game should probably make the decision from the start as to whether they want to use the DOM or the Canvas and stick to it.  Originally, I had intended The Render Engine to be able to "hot swap" rendering contexts but that paradigm just isn't feasible.  So I'm starting to wonder if I should do one of two things:

1. Focus on only creating the best engine for graphical contexts (canvas, web-gl, etc.)
2. Still support any context, but make the separation cleaner/clearer

Some feedback would be great because this would be a fundamental shift in the platform.  Neither one is a bad choice, but ideally the engine would be just an engine which allows the developer to make decisions for themselves rather than being limited by what the engine can do for them.  So, I ask you for some help in determining the future of The Render Engine... Vote in the poll and let us know your thoughts.