Re: [whatwg] Canvas-Only Document Type

The DOM and CSS obviously have a lot of utility that goes unused in
Canvas apps, but I think that, overall, the Web can benefit by
empowering Canvas.  It was originally brought to the platform with a
mentality influenced by embedded plugins (Flash), but now fullscreen
or full viewport experiences are much more prevalent and important for
high-impact content.  The platform must shift to regard those
experiences as the rule, not the exception.

As for accessibility, the Web is well overdue for a paradigm that can
handle more than document-oriented content with more than alt
"content".  That said, it would be simple to modify this proposal to
handle accessibility just as well as the Web does today for the same
use cases.  For example, one idea that is interesting to me is more
established use of the Speech Synthesis API for very interactive

On Mon, Jul 7, 2014 at 7:27 PM, Katelyn Gadd <> wrote:
> Too many use cases right now depend on the use of the DOM and CSS.
> Introducing this document model would require introducing a whole new
> set of APIs for solving those problems just for this particular corner
> case. Furthermore, removing the 'document' object throws away features
> you actually want...
> Some examples:
> CSS will still exist in this model since Canvas uses CSS for
> specification of things like fonts and colors.
> Web font loading is typically done at the document level in a
> stylesheet before you use the webfont in a canvas.
> Getting full dimensions for text is not (iirc) possible without using
> the DOM to create an invisible element containing the text, since the
> canvas measurement api only returns a width.
> Some important event listeners are registered on the document and/or
> elements, not the window.
> Various important content types are loaded via the DOM and (iirc)
> loads may not start or complete until they are added to the document's
> DOM tree. Without a document it would not be possible to load this
> content. (Scripts are the most obvious example; without a document how
> would you programmatically add scripts? IIRC video/audio/img have
> certain behaviors that only kick in once they are added to the DOM.)
> Pointer lock and fullscreen are defined in terms of document/elements,
> not the window.
> P.S. Handwaving in that fashion about accessibility is not a good
> idea. There's a huge subset of internet users out there that have real
> accessibility needs and it is not wise - or in some cases, even LEGAL
> - to dismiss them out of hand without careful consideration. The
> current web may not be IDEAL for accessibility, but throwing out the
> DOM is going to make your apps even worse in this regard.
> On Mon, Jul 7, 2014 at 4:06 PM, Brian M. Blakely
> <> wrote:
>> The use cases involved are mostly intended for 60fps high-load graphics, so the kind of a11y conditions served by the DOM (screen readers) aren't as helpful in these apps. I don't think the DOM makes videogames more accessible. The Web Platform doesn't serve that case well; it isn't something this is trying to solve.
>>> On Jul 7, 2014, at 6:54 PM, Silvia Pfeiffer <> wrote:
>>> Has anyone considered the accessibility implications of this? IIUC
>>> accessibility for canvas is provided through extra dom elements. So,
>>> this would defeat that purpose.
>>> Silvia.
>>> On Tue, Jul 8, 2014 at 8:39 AM, Brian M. Blakely
>>> <> wrote:
>>>> Hi Ashley,
>>>> With the budding of Canvas 2D and WebGL UI frameworks, I believe that, in a couple years' time, the role of CSS in the cases I described will diminish drastically. A lot of this was kind of waiting for Apple to give the OK before people began committing their hearts to WebGL.
>>>>> On Jul 7, 2014, at 5:17 PM, Ashley Gullen <> wrote:
>>>>> Having developed a major HTML5 game engine, and given this appears to be aimed at a gaming use case, I feel qualified to offer my opinion: I'm not sure this is a good idea.
>>>>> Despite being 99% canvas and javascript, we use CSS to implement some useful scaling modes (like letterbox fullscreen). We also use the DOM for many useful features, such as form controls, divs, Twitter or Facebook buttons and so on, which are positioned over the canvas. In particular text inputs are useful for things like name entry or logins even for games, and are typically difficult and error-prone to reimplement in only canvas and javascript.
>>>>> Is there any evidence that such a mode would actually improve performance? Are there benchmarks indicating the existence of a DOM, even if inert, harms performance in any way?
>>>>> Ashley Gullen
>>>>>> On 7 July 2014 21:35, Brian Blakely <> wrote:
>>>>>> Floating a concept for a document mode which eschews CSS and the DOM
>>>>>> to enable a more jank-free Canvas surface.
>>>>>> Depending on how this allows for optimization, might be used well for
>>>>>> games, VR, wearables, and ultra-portable or high-performance apps.
>>>>>> Probably most beneficial to memory usage and first paint time.  Would
>>>>>> appreciate if some vendor engineers who might be reading could chime
>>>>>> in on this point.
>>>>>> Strawman:
>>>>>> Document only contains <!doctype canvas-[2d|3d]> and script elements.
>>>>>> Everything else is ignored.  "document" object is gone.
>>>>>> A Canvas drawing surface consumes the entire viewport.  It always has
>>>>>> an opaque backing store, same as specifying getContext('2d', { alpha:
>>>>>> false }).
>>>>>> UA provides:
>>>>>> * A host object representing surface's CanvasRenderingContext2D or
>>>>>> WebGLRenderingContext (depending on specified doctype).
>>>>>> * In lieu of DOM, an API for creating offscreen canvases (actually,
>>>>>> this abstraction should probably exist anyway).  This might live on
>>>>>> the Context host obj, which may open a beneficial performance
>>>>>> relationship between onscreen canvas and offscreen "children".

Received on Tuesday, 8 July 2014 14:12:29 UTC