Re: canvas example

On 12/23/11 5:57 AM, Jonathan Mcdougall wrote:
> 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.

I was originally referring to your combobox implementation, which you 
have written in a single layer, to stay within specific bounds. I was 
sharing that it could be in two layers and work quite well.

You're correct about font sizes, dpi and themes. I have some old code 
(pre 2005) doing the old hover trick:
<button onmouseover='this.style.background = "lightblue"'>

It's no longer appropriate, as the button style changes in OS X. It 
needs style="-webkit-appearance: none" just to function how it used to.

I've worked hard to solve the DPI issue; Microsoft has a window.screen 
object sharing the appropriate DPI, Mozilla has CSS selectors, and 
WebKit has some quirks between inner and outer height, and they've OK'd 
Microsoft's method. For font size, CSS can be used to get information if 
wanted.

I was not suggesting mixing 
<select></select><canvas><select></select></canvas> in the same page: 
that would look a little awkward.

Just as my old <button> looks awkward on OS X when the appearance is 
upgraded by the system in some cases, and stays with the standard CSS 
box in others.


>>>> 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.

What do you mean about ARIA not being applicable to individual widgets?

Keep in mind, a single widget may be <input type="color">; that's a 
situation where the browser may support it, it may not. Implementing a 
fallback is in the current atmosphere, a good idea.

> 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.
Games are often quite complex; there are simpler games than first-person 
shooters, but even first person games can give additional hints to 
gamers about their use, through sound, alternate game play and other 
devices.

I believe I understand your point better: that canui is a scene graph, 
and its widgets are meant to be used together, not to just be picked 
individually. That certainly makes sense in any theme or scene graph 
library. I think we had a misunderstanding of what I was suggesting.


> 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.

We did have shadows of this topic early this year. It was not 
particularly fruitful, but I held strong to the concept that complex 
applications are not impossible to make accessible. I've been working to 
make a large Canvas project accessible; it's a highly graphical image 
editor. I've posted links about accessible games.

The purpose here is to expose information. When it's not exposed, then 
things are not accessible. When it's exposed, people have a chance to 
adapt and use that information in complex ways.

I'm happy to explore your understanding here.

For a very quick and easy view into what UA, OS and author-provided ARIA 
widgets expose to the accessibility interface, boot up IE9 or FF, and 
grab AViewer:
http://www.paciellogroup.com/blog/2010/06/aviewer-beta/

All widgets go through these interfaces; beyond that, they are all just 
pixels on the screen.

-Charles

Received on Friday, 23 December 2011 20:07:57 UTC