[whatwg] hit regions: limited set of elements for fallback content

Charles McCathie Nevile chaals at yandex-team.ru
Fri Feb 21 09:33:44 PST 2014


On Thu, 20 Feb 2014 22:38:18 +0100, Nils Dagsson Moskopp  
<nils at dieweltistgarnichtso.net> wrote:

> Dominic Mazzoni <dmazzoni at google.com> writes:
>
>> First a high-level thought.
>>
>> I'm happy to keep chasing after "legitimate" use-cases instead of  
>> contrived ones, but just because we can't think of one, doesn't mean it
>> doesn't exist... Maybe the
>> vast majority of web apps that use canvas for a grid, or a slider, or a
>> list box would be better off using standard html5 objects. But what if
>> there's one app that can't, for some reason we haven't anticipated?
>> If we wait until that app appears to allow that control to have a hit
>> region, then it will be months or years before that app can be
>> accessible.

Which is why I think the "but it shouldn't be done that way" argument  
needs to be viewed through the prism of the question "but will it"?

History strongly suggests that people will use canvas because it suits  
them, whatever "experts" like us say they *should* do.

>> More below:
>>
>> On Tue, Feb 18, 2014 at 1:16 PM, Ian Hickson <ian at hixie.ch> wrote:
>>
>>> On Tue, 18 Feb 2014, Dominic Mazzoni wrote:
>>> > On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson <ian at hixie.ch> wrote:
>>> > > > I'm curious if it's possible to implement an accessible list box  
>>> > > > or other select control in a canvas. Wouldn't it be possible to  
>>> > > > make it accessible if the canvas lets you focus the list box by
>>> > > > clicking on its hit region, and then change the selection using
>>> > > > the arrow keys?
>>> > >
>>> > > What's the concrete use case?
>>> >
>>> > How can I get more concrete than there's a list box inside a canvas?
>>>
>>> Well for example, is the use case one of the controls on Bugzilla's
>>> advanced search page?:
>>>
>>>    https://www.w3.org/Bugs/Public/query.cgi?format=advanced
>>>
>>> If so, I feel comfortable saying that we don't need to make <canvas>
>>> support that, since that use case is already handled very well by the
>>> <select> element.

It probably is for bugzilla.

It isn't for the case where somebody wants a dropdown menu for selecting  
things, that matches the particularities of their site design.

Nor does <select> work for the case where the site is being built by  
someone who wants to ensure that their CSS can't be overridden; I don't  
know why people think this, but many still do.

It apparently isn't for search suggestions. Whatever the reason, Yandex  
search doesn't use it for their suggestions. While they don't use canvas  
either, it seems that select is not sufficient for Yandex. Nor is it used  
by Google, Yahoo, Bing or Baidu for the task. And none of them have a  
complicated layout to work with. But they all use styled text elements.

>> I'll try, though: what if I had a list of choices displayed as a pie  
>> chart?
>> Each slice of the pie is a focusable object that, when you click on it,
>> allows you to take an action on that pie slice.
>
> What if I look at that page in a textual user agent?

Where the hit regions are based on a list as 'fallback content'? You get a  
list. With links that match the actions. If the developer got  
accessibility right.

But if they would only get it a bit right, it seems stupid to suggest that  
we should gratuitously deny them the option - letting perfect be the enemy  
of good here is an extremely effective way to reduce accessibility, which  
is very rarely done perfectly.

>> Surely you'd agree that rendering a pie chart is a natural use-case for  
>> the canvas element.
>
> Nope. If it is just decoration, you should use CSS. Look at source code:
> <http://daten.dieweltistgarnichtso.net/src/css-pie-chart-form.html>
>
> (For pages like these, I have a hotkey for “disable CSS”.)

But you are not a scalable resource, just an anecdotal data point. When  
Opera wanted to publish statistical tables in their "State of the Mobile  
Web" reports, their Web designers felt that canvas was the obvious way to  
do so. When accessibility expert Steve Faulkner wanted an example of  
canvas to make accessible he used an interactive pie chart.

http://yandex.com/yandsearch?text=pie%20chart%20canvas suggests that a lot  
of people appear to think it is a natural thing to do. I got ~310k  
answers, and while not all of them will be about using canvas to make pie  
charts the overwhelming majority of the first few pages are.

So it appears that there *are* use cases for this, and that people go to  
the effort of doing it, whether or not it is a good idea.

>> I know it's technically possible in css, but it's quite
>> tricky - whereas it's simple and natural in canvas. And there are  
>> plenty of shapes that are basically impossible in pure CSS.
>
> I might consider that a good thing.

You may do. Many front-end developers I work with find it a limitation.  
Beyond all these anecdotes, rounded corners offers plenty of evidence that  
designers will use all manner of techniques that you and I probably agree  
are unhelpful, to achieve their visual design goals.

> May I ask if you have designed
> human-computer interfaces. If so, may you provide examples?

I'm not sure how that is relevant.

>>> > What if I do want a <select>, but I just want a canvas to render it
>>> > visually?
>>>
>>> Are Web Components and CSS unable to get the effects you need? Maybe we
>>> should be improving those rather than <canvas>. It's hard to tell  
>>> without knowing precisely what you want to do.
>
> This requests reminds me of customers wanting “page intro in flash.”.

And the response reminds me of http://xkcd.com/1319/

>>> If a region has a car theft problem, you don't solve it by giving all  
>>> the thieves the car keys. You solve it by improving the economy so that
>>> thieves have better things to do (like get an interesting job), and you
>>> solve the remainder by improving law enforcement. The same applies  
>>> here.
>>> We solve it by providing better tools for custom text editing controls
>>> (e.g. better contenteditable APIs), and by making it non-conforming to
>>> abuse <canvas> for this purpose.

Only if that actually stops people using canvas for this purpose.

>> I'd suggest a different analogy: suppose your company makes foam pipe
>> insulation and you discover people are buying your product and using it  
>> as a swimming pool flotation device. Do you try to stop them from using  
>> your product and try to get them to purchase other pool toys, or do you
>> start selling your pipe insulation directly to the sporting goods
>> stores?
>
> You might check if the pipe insulation is toxic, first.

Actually, our role here is to aniticipate what the insulation suppliers of  
Shenzhen, Minneapolis, Alberta, Yakutsk, and Badaginnie would do, and try  
to make sure it works out OK.

And while we might disagree about what they *should* do, in practice it  
seems that some developers will use canvas for almost any kind of  
rendering, probably including things we can't even imagine.

cheers

Chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals at yandex-team.ru         Find more at http://yandex.com



More information about the whatwg mailing list