Re: canvas example

On 12/22/11 4:00 PM, Jonathan Mcdougall wrote:
> On Thu, Dec 22, 2011 at 6:00 PM, Charles Pritchard<chuck@jumis.com>
> wrote:
>> On 12/22/11 2:44 PM, Jonathan Mcdougall wrote:
>>> On Thu, Dec 22, 2011 at 2:32 PM, Charles Pritchard<chuck@jumis.com>
>>> wrote:
>>>
>>>> So for example, with your application, it makes the most sense to
>>>> have a combobox look like:<canvas role="combobox" tabindex="0"
>>>> aria-label="select an item"></canvas>
>>> Although every control can live in its own<canvas>, I never thought
>>> of using it this way. I was expecting the various controls to be
>>> part of a larger canvas. One of the difficulties is with floating
>>> elements such as menus or comboboxes, where the canvas needs to
>>> extend past the bounds of the control while in a normal state,
>>> giving trouble with the flow around it.
>> This is a place where ARIA markup is a big help. You might have
>> aria-haspopup in addition to role="combobox", and create another
>> canvas layer for that popup.
> True, but aria has nothing to do with it. 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. I also like to keep a minimum of Canvas layers.


>>> I'm also not sure what we're talking about here. I'm reading on
>>> this mailing list about how<canvas>  shouldn't be used to replace
>>> native controls (which I mostly agree with), but you seem to
>>> suggest otherwise.
>> ARIA was designed in response to developers creating form controls
>> by using<div>,<ul>  and the like. The same applies for Canvas.
>> [...]
>>
>> There is no<spreadsheet>  tag, in HTML, for instance. So we have to
>> glue a bunch of primitives together.  ARIA is the language of those
>> low level primitives.
> Okay, are we talking about aria or<canvas>? I was not prepared to
> discuss accessibility concerns and I don't know much about aria,
> except that it is metadata about semantics. Honestly, this is not a
> subject that interests me much, unfortunately.

ARIA is about UI semantics. Where Canvas does the low-level pixel 
pushing, ARIA does the low level pushing of state data. Both of them are 
shipped through to the OS. Typically, you'll have a lot of your UI state 
data locked away in your scripting environment, in private variables. 
While that's fine, exposing various pieces of data to the DOM through 
ARIA attributes is a big help in a few ways. So I often bring it up to 
anyone working with Canvas and UI.


> I jumped into this discussion without reading old threads, although I
> did look at the ones from October to December. I have never
> contributed or read the w3c mailing lists, so I apologize if this is
> an ongoing discussion about aria, which would make me off-topic here.
>

You're not off-topic, the role of ARIA in UI is an often-repeated topic 
(that I often steer toward). ARIA was created when it was noticed that 
authors were creating their own interactive controls.

> Concerning<spreadsheet>, I'm not sure whether you are suggesting that
> implementing one in a canvas would be better than using html elements.
> If you are, then I disagree. Canvas ignores any kind of user settings
> about colors, fonts, themes or images. Using it for graphical
> applications works fine, but not for office applications.
>
> But again, you might be talking about aria, in which case, I'm not
> sure what to respond.

Whatever you use to implement a spreadsheet, it makes sense to have ARIA 
attributes.
I like to think of this class of application as authoring tools.

User settings are, in some part, exposed through CSS. It's up to the 
Canvas author to pull that data, or to provide alternatives to the user 
to set their own themes. But that's a little off topic. I wasn't 
suggesting any particular implementation style for writing a 
spreadsheet. I'm just saying, they are difficult and there is a complex 
relationship between otherwise simple form components. That's different 
than say, a <fieldset>, which will not have particularly complex 
relationships.

>> 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. Most of it is feasible (some is implemented on canui, more
> would be if I had the interest), some is candy (spell checking) and
> a few are currently impossible (ime, d&d, etc.) None of them is a
> show-stopper though, as long as the goal is not to reproduce native
> widgets.

D&D is quite possible with the dataTransfer API. I believe Hironori Bono 
is still working on an IME api.

As a general practice, most web apps would do best to use bare HTML4 
elements. But, for style and other purposes, they often upgrade those 
elements with additional features and semantics. I've always tried to 
start with <input> and work from there... many people have written their 
own input type=color, date and the like, several times over.

Basic text editing, unless it's a highly stylized WYSIWYG or custom 
script, is better left to HTML4.

Highly stylized items, and as you've noted, in-game assets, have more 
reason to be challenging the author's programming abilities.


> 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've seen UI components from the OS re-implemented by UAs at times, and 
other times, the OS implementation is passed through and styled. In some 
cases, the UA fails to implement the semantics that are present in the 
OS. In some cases, the UA style is much more pleasing or flexible. The 
same applies to author-created and library-imported widgets.

I appreciate you taking the time to have this conversation with me. 
public-canvas-api is an open list and you're free to post here any time.

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. When you do dive into Canvas again, I strongly recommend 
looking at ARIA as an accompaniment to Canvas.


-Charles

Received on Friday, 23 December 2011 06:41:52 UTC