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 <silviapfeiff...@gmail.com> 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
> <anewpage.me...@gmail.com> 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 <ash...@scirra.com> 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
>>> Scirra.com
>>>
>>>
>>>
>>>> On 7 July 2014 21:35, Brian Blakely <anewpage.me...@gmail.com> 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".
>>>
