W3C home > Mailing lists > Public > public-canvas-api@w3.org > October to December 2011

Re: canvas example

From: Jonathan Mcdougall <jonathanmcdougall@gmail.com>
Date: Fri, 23 Dec 2011 08:57:10 -0500
Message-ID: <CAP_q9LxH_bBmQksA++eEmLizUL2r+AUiiLEhQDgLiaZCo4pdzA@mail.gmail.com>
To: Charles Pritchard <chuck@jumis.com>
Cc: public-canvas-api@w3.org
On Fri, Dec 23, 2011 at 1:41 AM, Charles Pritchard <chuck@jumis.com>
wrote:
> On 12/22/11 4:00 PM, Jonathan Mcdougall wrote:
>> On Fri, Dec 23, 2011 at 1:41 AM, Charles Pritchard
>> <chuck@jumis.com> wrote:
>>
>> I don't like using any kind of device that breaks or interferes
>> with the normal flow of a page and wouldn't agree that a combobox
>> implemented as one or more layers of <canvas>  is good idea.
>> Although I'm not sure if that's what you're saying.
>
> I'm not quite sure what you're describing about the normal flow of a
> page.
>
> In the case of a combobox, you would use position: absolute and
> element.insertBefore when the popup is triggered. It does not cause
> a reflow.

But this assumes that the library is able to replicate the native
behaviour. Different font sizes, dpi and windowing system themes will
make the combobox look out of place. It might make it too big or too
small compared to the text around it, or whatever. This is what I
meant by the normal flow of a page.

I also included look-and-feel in "normal flow", but this might be a
misuse of the term.

>>> For what it's worth, I also agree with section 4.8.11.1.13 Best
>>> Practices as published by the WHATWG.
>>
>> I don't. [...] All of these caveats also apply to games running on
>> the desktop that don't use the windowing system's native controls,
>> but it never stopped games from being made.
>
> We have on occasion, seen consensus on that last part: whatever
> caveats exist for developing widgets in the scripting environment,
> people are still going to go ahead and make those widgets. We saw
> that with HTML4 and custom widgets, necessitating ARIA, and we're
> seeing that with HTML5 as well.

I still think reimplementing single widgets in canvas is a bad idea,
aria or not. Using a custom user interface in a canvas as part of a
larger application is fine, but then aria couldn't be applied to
individual widgets.

In the example page for canui, the purpose of putting controls in
discrete canvas elements was to clearly show their appearance and
behaviour, not to encourage using them individually.

I can imagine separating a game into multiple canvas elements, such as
one for each widget in a menu, but this is convoluted and would only
work if the widgets can be easily isolated from the main game
interface. However, this would be of little help since the bulk of the
game (such as combat in a first-person shooter) would still not be
accessible.

I see little use for aria here: individual widgets are better
implemented as html elements, while a more complex application is
intrinsically impossible to make accessible.

-- 
Jonathan McDougall
Received on Friday, 23 December 2011 13:57:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 23 December 2011 13:57:59 GMT