Re: [whatwg] hit regions: limited set of elements for fallback content
Nils Dagsson Moskopp wrote: But still, people (with the exception of Paul Graham) stopped using table for layouts if only that were true, take a look at https://www.google.co.uk or grep the html data available from http://webdevdata.org Also, Faulkner wanting an example of canvas to make accessible ... seems like circular reasoning to me to use that as an example why we need an accessible canvas. ? -- stevef
Re: [whatwg] hit regions: limited set of elements for fallback content
Steve Faulkner faulkner.st...@gmail.com writes: Nils Dagsson Moskopp wrote: But still, people (with the exception of Paul Graham) stopped using table for layouts if only that were true, take a look at https://www.google.co.uk or grep the html data available from http://webdevdata.org Thanks for pointing out that my assumption was unfounded. I am downloading one of the data sets right now. Also, Faulkner wanting an example of canvas to make accessible ... seems like circular reasoning to me to use that as an example why we need an accessible canvas. ? 1. A wants to demonstrate how technology X can do Y. 2. B: „because A wants to demonstrate how X does Y, we need X to do Y“. reduces to: 3. “X should do Y because someone wants to show how X can do Y.” Am I misunderstanding the argument by a large margin? ?Btw, I have actually read some of your posts regarding canvas accessability and am aware you list quite a lot of arguments.) -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] hit regions: limited set of elements for fallback content
hixie wrote:
But there's plenty of things which make zero sense as fallback content.
input type=color, for example, simply cannot be sanely implemented in
canvas
as implemented input type=color is a button that when activated pops up a
picker dialog. So the following code (as a simple example)
canvas id=myCanvas width=200 height=100
style=border:1px solid #00;
onclick=document.getElementById('button').click();
input type=color id=button
/canvas
in Firefox 30/windows when the canvas is clicked the color picker is
displayed., likewise if the the input receives focus via the keyboard and
the enter/spacebar key is pressed the picker dialog is displayed.
--
Regards
SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/
Re: [whatwg] hit regions: limited set of elements for fallback content
On Fri, 21 Feb 2014 09:47:51 +0100, Steve Faulkner
faulkner.st...@gmail.com wrote:
hixie wrote:
But there's plenty of things which make zero sense as fallback content.
input type=color, for example, simply cannot be sanely implemented in
canvas
I don't want to pronounce on sanity, but I don't think it has ever been a
major criterion for whether people *will* do something on the Web.
And it seems pretty easy to make a colour picker in canvas. I can imagine
that anyone who wanted a specific-purpose color picker (styled to match
the site, or customising the options, or...) would do it in canvas or SVG,
and my guess is the former would be more common...
cheers
Chaals
as implemented input type=color is a button that when activated pops up a
picker dialog. So the following code (as a simple example)
canvas id=myCanvas width=200 height=100
style=border:1px solid #00;
onclick=document.getElementById('button').click();
input type=color id=button
/canvas
in Firefox 30/windows when the canvas is clicked the color picker is
displayed., likewise if the the input receives focus via the keyboard and
the enter/spacebar key is pressed the picker dialog is displayed.
--
Regards
SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/
--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] hit regions: limited set of elements for fallback content
On Fri, 21 Feb 2014, Steve Faulkner wrote:
But there's plenty of things which make zero sense as fallback content.
input type=color, for example, simply cannot be sanely implemented in
canvas
as implemented input type=color is a button that when activated pops up
a picker dialog.
Only on some platforms.
So the following code (as a simple example)
canvas id=myCanvas width=200 height=100
style=border:1px solid #00;
onclick=document.getElementById('button').click();
input type=color id=button
/canvas
in Firefox 30/windows when the canvas is clicked the color picker is
displayed. likewise if the the input receives focus via the keyboard and
the enter/spacebar key is pressed the picker dialog is displayed. --
And that's great if you happen to have that exact implementation. But what
about implementations where a colour palette drops down or is shown inline?
On Fri, 21 Feb 2014, Charles McCathie Nevile wrote:
I don't want to pronounce on sanity, but I don't think it has ever been
a major criterion for whether people *will* do something on the Web.
Sure. What we're talking about here is just how to guide people into what
is more sane. This is a big part of what language design, especially
opinionated language design, is all about.
And it seems pretty easy to make a colour picker in canvas. I can
imagine that anyone who wanted a specific-purpose color picker (styled
to match the site, or customising the options, or...) would do it in
canvas or SVG, and my guess is the former would be more common...
Building a colour picked in canvas would be easy. Making it accessible
using a backing logic based on radio buttons, a list box, or regular
buttons, would be easy. Making it acessible based on input type=color
would not work at all.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hit regions: limited set of elements for fallback content
On Thu, 20 Feb 2014 22:38:18 +0100, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Dominic Mazzoni dmazz...@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 i...@hixie.ch wrote: On Tue, 18 Feb 2014, Dominic Mazzoni wrote: On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson i...@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
Re: [whatwg] hit regions: limited set of elements for fallback content
Charles McCathie Nevile cha...@yandex-team.ru writes: On Thu, 20 Feb 2014 22:38:18 +0100, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Dominic Mazzoni dmazz...@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. People also used table for layout and created unskippable flash intros. Web programming might resemble pop culture – it has trends like visitor counters that came and thankfully went away (but then were hip again to show the number of likes or retweets). But still, people (with the exception of Paul Graham) stopped using table for layouts and also do rely less on flash for video content than they did seven years ago. More below: On Tue, Feb 18, 2014 at 1:16 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 18 Feb 2014, Dominic Mazzoni wrote: On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson i...@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. The user should *always* have control. People who “want to ensure that their CSS can't be overridden” are enemies of usability, accessability, by extension also enemies of security and – ultimately – proponents of Digital Restrictions Management. Btw, I use a fixed font and a high contrast GTK+ theme myself – both apply to form controls to make them more usable. 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. Please elaborate: What do you think you can infer from this? Maybe I have not understood the problem these search engines all seem to have. 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. If. Contrast the CSS solution, where just removing the obnoxious styling (or visiting the page in a w3m) shows a perfectly usable form – without any additional work from the developer. 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. There are already quite easy options to build accessible web forms. If an author chooses to not make a web page beautiful and sacrifices accessability, that person is certainly optimizing for style and not particularly caring about accessability. I consider this a social problem that may partially be overcome by designing standards (like document formats or protocols) in a way that there exists a way of least resistance for lazy developers. People do accept that some problems can not be solved given
Re: [whatwg] hit regions: limited set of elements for fallback content
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. As Alan Perlis said, Every program has (at least) two purposes: the one for which it was written and another for which it wasn't. 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. More below: On Tue, Feb 18, 2014 at 1:16 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 18 Feb 2014, Dominic Mazzoni wrote: On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson i...@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. As I argued above, maybe we can't come up with a really good use-case, but that doesn't mean one doesn't exist. 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. Surely you'd agree that rendering a pie chart is a natural use-case for the canvas element. 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. But how should the list of pie slices behave if you were interacting with the pie chart using the keyboard? Why not a list box? Conceptually you just have a list of elements, one of which can be selected at a time. Whether or not we think it's a good idea, people are building entire UIs using canvas. Sometimes it's in order to achieve pixel-perfect rendering accuracy across browsers and platforms, sometimes it's for speed, sometimes it's for visual effects that aren't possible in HTML, sometimes it's because they're building a cross-platform UI. Just because people do it doesn't mean we need to design our APIs around it, or otherwise endorse it. For example, people use table elements for layout purposes, but this is expressively against the table conformance requirements. People use blockquote for indenting, but instead of providing a blockquote indent-depth attribute, we improve CSS to support indenting. And so on. Even though you're not supposed to use table for layout, is there any part of the HTML spec that forbids placing a certain element inside a table cell because the only legitimate reason to do so would be if it was a layout table? I'm not aware of one. Similarly, I think it'd be simplest to just allow any element to be the target of a hit region. We can still discourage it, but fail gracefully if authors decide to abuse it. Asking web developers not to build UIs in canvas is like asking Windows, Mac, iOS, or Android developers to not build custom controls. It's not going to happen. Sure, but that misses the point a little. We are developing technologies for custom controls -- Web components. To support a select drop-down, you need much more than just a canvas: you need a way to show a popup window, you need a way to draw shadows over underlying content, etc. Yes, and people are building replacements for select using web components now, like polymer-ui-menu: http://www.polymer-project.org/components/polymer-ui-menu/smoke.html It should be easy to make something like polymer-ui-menu accessible using role=listbox and role=option under the hood. The question is, why shouldn't it be possible to implement a polymer-ui-canvas-menu that works the same way but uses a canvas to render? So this is why I ask for the precise use cases. We can only evaluate if the technologies are actually addressing needs by going through and seeing how they do with precise use cases. If the use cases are very vague, we can at best guess, and we might guess poorly. 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. Is my pie chart example
Re: [whatwg] hit regions: limited set of elements for fallback content
On Thu, 20 Feb 2014, Dominic Mazzoni wrote: 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. As Alan Perlis said, Every program has (at least) two purposes: the one for which it was written and another for which it wasn't. 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. The problem is that without knowing what the unanticipated app is, we can't possibly design for it. Trying to design APIs blindly results in poor APIs. As I argued above, maybe we can't come up with a really good use-case, but that doesn't mean one doesn't exist. But it _does_ mean we can't possibly design for it. 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. Isn't that handled by just a series of buttons corresponding to each slice? I don't really understand why you'd need a list box here. But how should the list of pie slices behave if you were interacting with the pie chart using the keyboard? Why not a list box? Conceptually you just have a list of elements, one of which can be selected at a time. I think conceptually you have a series of buttons. It would be more like a list box if instead of each slice being activatable, the slices were selectable, maybe multiple slices being selectable such that you can then operate on them as a group. That does seem like a reasonable use case. It would argue for allowing select size=n where n1, and for select multiple. It's a bit weird to require that we explicitly give the size for a fallback select, so maybe we should instead just say that any select size=1 that's in canvas fallback is automatically assumed to have a non-1 size? Would that be reasonable to implement? Even though you're not supposed to use table for layout, is there any part of the HTML spec that forbids placing a certain element inside a table cell because the only legitimate reason to do so would be if it was a layout table? We've made lots of elements non-conforming, e.g. font. Looking at tables specifically, there's no element that was previously only allowed in tables that has since been disallowed (all the elements we've disallowed from table were also allowed elsewhere before and are disallowed everywhere now), but there's lots of _attributes_ on table, td, etc, that we've made non-conforming for the same reason: table bgcolor table border table bordercolor table cellpadding table cellspacing table width td align td bgcolor ...etc. Plus of course we don't allow any elements that aren't currently in HTML. Similarly, I think it'd be simplest to just allow any element to be the target of a hit region. We can still discourage it, but fail gracefully if authors decide to abuse it. I'm all for allowing things which have reasonable use cases. But there's plenty of things which make zero sense as fallback content. input type=color, for example, simply cannot be sanely implemented in canvas, because we don't provide the right hooks. Similarly for select size=1, in its normal form (i.e. assuming we don't special-case it to turn it into a listbox rather than a drop-down widget). Sure, but that misses the point a little. We are developing technologies for custom controls -- Web components. To support a select drop-down, you need much more than just a canvas: you need a way to show a popup window, you need a way to draw shadows over underlying content, etc. Yes, and people are building replacements for select using web components now, like polymer-ui-menu: http://www.polymer-project.org/components/polymer-ui-menu/smoke.html (Loading that page shows why it's terrible to design new widgets from scratch instead of building them on existing fallback elements, by the way. It's a completely unusable page with near zero semantics. Completely inaccessible, even to non-AT users, all because the scripts can't load.) It should be easy to make something like polymer-ui-menu accessible using role=listbox and role=option under the hood. The question is, why shouldn't it be possible to implement a polymer-ui-canvas-menu that works the same way but uses a canvas to render? I think it's a fine use case that we should enable. We just need to work out what to do regarding select size=1, as discussed above. 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
Re: [whatwg] hit regions: limited set of elements for fallback content
On Thu, Feb 20, 2014 at 10:37 AM, Ian Hickson i...@hixie.ch wrote: So far, it seems like to support grids in canvas, we need: - enable table-related elements (table, td, tfoot, etc) to be hit region controls. (exclude col and colgroup) - fire an event on an element when the user agent (possibly because of a request from the AT, but not necessarily) wants to scroll to an element; default action is to actually scroll. - when this event is fired on a canvas, include the region information. ...and to support list boxes, we need: - enable select multiple elements to be hit region controls. - enable select size=N eements where N1 to be hit region controls. - enable option to be hit region controls. - optionally, if implementors are on board: - make select size=1 in canvas act like size=N where N1. - enable select size=1 elements to be hit region controls. This all sounds great. Are there any other use cases we should address? Possibly, but this is a great start for now. I'll post more use cases as I uncover them or think of them. What's your take on the select thing; should we have a special case in browsers for size=1, or should we require size1? I can't think of a way to make size=1 work, so requiring size1 may be the only option. It seems ugly, though. - Dominic -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hit regions: limited set of elements for fallback content
On Thu, 20 Feb 2014, Dominic Mazzoni wrote: On Thu, Feb 20, 2014 at 10:37 AM, Ian Hickson i...@hixie.ch wrote: So far, it seems like to support grids in canvas, we need: - enable table-related elements (table, td, tfoot, etc) to be hit region controls. (exclude col and colgroup) Filed this as: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24750 - fire an event on an element when the user agent (possibly because of a request from the AT, but not necessarily) wants to scroll to an element; default action is to actually scroll. - when this event is fired on a canvas, include the region information. Filed this as: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24748 ...and to support list boxes, we need: - enable select multiple elements to be hit region controls. - enable select size=N eements where N1 to be hit region controls. - enable option to be hit region controls. - optionally, if implementors are on board: - make select size=1 in canvas act like size=N where N1. - enable select size=1 elements to be hit region controls. Filed this as: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24749 What's your take on the select thing; should we have a special case in browsers for size=1, or should we require size1? I can't think of a way to make size=1 work, so requiring size1 may be the only option. It seems ugly, though. The way we could make it work would be to change the logic in the select so that when it's in a canvas, it's a list box and not a drop-down. But that might be more confusing than requiring that people set size=2? I guess I'll just punt on this for now and we'll see whether authors get confused or not. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hit regions: limited set of elements for fallback content
Dominic Mazzoni dmazz...@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. As Alan Perlis said, Every program has (at least) two purposes: the one for which it was written and another for which it wasn't. 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. More below: On Tue, Feb 18, 2014 at 1:16 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 18 Feb 2014, Dominic Mazzoni wrote: On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson i...@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. As I argued above, maybe we can't come up with a really good use-case, but that doesn't mean one doesn't exist. Absence of evidence is at least weak evidence of absence. Quote http://rationalwiki.org/wiki/Absence_of_evidence: You hear some rustling noises in your backyard, and you want to figure out if the noises were caused by your neighbor's dog or by some other intruder. Fortunately, you know what your neighbor's dog is like - he's rambunctious and he barks constantly. So you listen closely, and after 20 minutes you don't hear any barking. What should you conclude? 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? 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”.) 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. May I ask if you have designed human-computer interfaces. If so, may you provide examples? 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.”. 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. 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. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] hit regions: limited set of elements for fallback content
On Mon, Feb 17, 2014 at 11:02 PM, Ian Hickson i...@hixie.ch wrote: What about select? What about it? 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? Sure. addHitRegion() supports roles like menuitem this in two ways: If you're doing something like a straight-forward menu item, you can just add the text and the role directly. If you're doing something more elaborate (e.g. a menu with disabled items), you can add appropriate elements (e.g. button) representing the menu into the canvas fallback content, and use ARIA roles and properties to override button's defaults. That sounds fine. Once you get to more elaborate compound controls like spin buttons, you really shouldn't be using canvas in the first place, and so those aren't supported (spinbutton in particular would be impossible to correctly support in a canvas, since it's a compound control with multiple subregions, all corresponding to a single DOM node on the ARIA side). Spinbutton is probably a bad example. What about a list box using ARIA instead? canvas div role=listbox div role=option tabindex=0First option/div div role=option tabindex=-1Second option/div div role=option tabindex=-1Third option/div /div /canvas It seems to me that I could make each visible option a hit region - why couldn't we make this work? Simple grids are supported the same way that simple menuitems are supported; again, though, once you get to elaborate grids with cells that can be marked invalid, marked as having popups, etc, you really shouldn't be using canvas, so those aren't supported. So you don't think people are going to implement something like a spreadsheet using canvas? That's what table is for. If you want a table with graphics inside, the way to do that is to have a table with each td containing a canvas, not a single canvas. This is relatively important because users really don't want authors reimplementing table navigation themselves -- indeed I'm not even sure it's technically possible for an author to track the AT focus as the user navigates a table using AT commands, so it would be incredibly difficult for an author to do a good reimplementation of a grid on canvas. If there are specific use cases for why you'd want to recreate a table using canvas, please do describe it. If we need to support this, then we should make sure we do a good job (as noted, the current APIs aren't sufficient, even if we just make addHitRegion() support pointing to td elements in the canvas fallback content). A spreadsheet is one possible use-case, though I agree it's complicated. How about a crossword puzzle game as a more realistic example, where the author wants to draw the whole puzzle in a canvas, not put a canvas inside each cell? The accessible fallback content could use a table, and but each cell would be focusable and have a role of gridcell. Games like tic-tac-toe, chess, or reversi would also be reasonable use-cases to consider for this. - Dominic -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hit regions: limited set of elements for fallback content
On Tue, 18 Feb 2014, Dominic Mazzoni wrote: On Mon, Feb 17, 2014 at 11:02 PM, Ian Hickson i...@hixie.ch wrote: What about select? What about it? 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? Right now, this is intentionally not possible, since it seems that if you want a select, you really should be using a select, not a canvas. But if there's a valid reason to have a list box or other select control in a canvas, then we should examine that reason and see what precisely is needed to make it possible. (It's probably a lot more than just exposing a select, since you'd need some way to map the open select popup's focus to canvas, and there's no API to do that currently.) What about a list box using ARIA instead? canvas div role=listbox div role=option tabindex=0First option/div div role=option tabindex=-1Second option/div div role=option tabindex=-1Third option/div /div /canvas Why would you use divs in the canvas fallback? Just use the real control, like a select. But see above for the case of select specifically; it's not that simple in practice. It seems to me that I could make each visible option a hit region - why couldn't we make this work? We can make anything work if we want to; the question is what do we need to make work. Simple grids are supported the same way that simple menuitems are supported; again, though, once you get to elaborate grids with cells that can be marked invalid, marked as having popups, etc, you really shouldn't be using canvas, so those aren't supported. So you don't think people are going to implement something like a spreadsheet using canvas? No, canvas would be a disaster for implementing a spreadsheet. You'd have all of the problems already described for text controls: http://whatwg.org/html#best-practices ...plus a whole new set of problems relating to how to expose navigating a grid (right now there's no API for determining where the AT focus on a table is, so you couldn't just map a fallback table to a canvas rendering, it wouldn't work). A spreadsheet is one possible use-case, though I agree it's complicated. The spreadsheet use case is already handled by table. If the problem is that we need something more performant than DOM+CSS, then we should provide something for that. Providing a pixel pushing interface is no real solution (see the #best-practices link above for a long list of reasons why not). This is the same reason that a spreadsheet is not a good use case for introducing a mechanism to do underlining: http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Jan/0068.html How about a crossword puzzle game as a more realistic example, where the author wants to draw the whole puzzle in a canvas, not put a canvas inside each cell? Why would you use a canvas for a cross-word puzzle, rather than a table? Games like tic-tac-toe, chess, or reversi would also be reasonable use-cases to consider for this. For 2D versions, why wouldn't you use a table? I don't understand what the cavnas is bringing to the table here. For 3D versions, the addHitRegion() API doesn't apply, so that seems like a separate issue. But ok, let's look at a 2D grid like chess or a cross-word. What would you actually need to make that work? canvas table onkeypress=handleKeyInput tr td tabindex=0 I td tabindex=0 N tr td tabindex=0 F td class=black aria-readonly=false /table /canvas What happens if the user navigates the table with their AT and moves the AT focus to the fourth cell? It's not focusable, but do we still need to be telling the AT where the cell is? What happens if we haven't told it where the cell is? Where is the keyboard focus while the AT focus is on the black cell? Imagine the crossword is so large that it doesn't fit on the canvas, and so the script scrolls the canvas around as the user tabs from cell to cell. Now what happens when the user moves AT focus to a black cell that isn't currently being rendered? Do we have some way to find out that a region is being AT focused? What happens if the keyboard focus and the AT focus get so far from each other that we can't render both at the same time? Which should we be rendering? How do native apps handle these cases? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hit regions: limited set of elements for fallback content
On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 18 Feb 2014, Dominic Mazzoni wrote: On Mon, Feb 17, 2014 at 11:02 PM, Ian Hickson i...@hixie.ch wrote: What about select? What about it? 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? Right now, this is intentionally not possible, since it seems that if you want a select, you really should be using a select, not a canvas. But if there's a valid reason to have a list box or other select control in a canvas, then we should examine that reason and see what precisely is needed to make it possible. (It's probably a lot more than just exposing a select, since you'd need some way to map the open select popup's focus to canvas, and there's no API to do that currently.) What about a list box using ARIA instead? canvas div role=listbox div role=option tabindex=0First option/div div role=option tabindex=-1Second option/div div role=option tabindex=-1Third option/div /div /canvas Why would you use divs in the canvas fallback? Just use the real control, like a select. But see above for the case of select specifically; it's not that simple in practice. It seems to me that I could make each visible option a hit region - why couldn't we make this work? We can make anything work if we want to; the question is what do we need to make work. Simple grids are supported the same way that simple menuitems are supported; again, though, once you get to elaborate grids with cells that can be marked invalid, marked as having popups, etc, you really shouldn't be using canvas, so those aren't supported. So you don't think people are going to implement something like a spreadsheet using canvas? No, canvas would be a disaster for implementing a spreadsheet. You'd have all of the problems already described for text controls: http://whatwg.org/html#best-practices ...plus a whole new set of problems relating to how to expose navigating a grid (right now there's no API for determining where the AT focus on a table is, so you couldn't just map a fallback table to a canvas rendering, it wouldn't work). A spreadsheet is one possible use-case, though I agree it's complicated. The spreadsheet use case is already handled by table. If the problem is that we need something more performant than DOM+CSS, then we should provide something for that. Providing a pixel pushing interface is no real solution (see the #best-practices link above for a long list of reasons why not). This is the same reason that a spreadsheet is not a good use case for introducing a mechanism to do underlining: http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Jan/0068.html How about a crossword puzzle game as a more realistic example, where the author wants to draw the whole puzzle in a canvas, not put a canvas inside each cell? Why would you use a canvas for a cross-word puzzle, rather than a table? Because it is easier to code a nice interface. See this Google doodle: http://www.google.com/logos/2013/crossword/crossword13.html It's fully keyboard navigable but inaccessible since the grid is drawn with canvas. Games like tic-tac-toe, chess, or reversi would also be reasonable use-cases to consider for this. For 2D versions, why wouldn't you use a table? I don't understand what the cavnas is bringing to the table here. For 3D versions, the addHitRegion() API doesn't apply, so that seems like a separate issue. But ok, let's look at a 2D grid like chess or a cross-word. What would you actually need to make that work? canvas table onkeypress=handleKeyInput tr td tabindex=0 I td tabindex=0 N tr td tabindex=0 F td class=black aria-readonly=false /table /canvas What happens if the user navigates the table with their AT and moves the AT focus to the fourth cell? It's not focusable, but do we still need to be telling the AT where the cell is? What happens if we haven't told it where the cell is? Where is the keyboard focus while the AT focus is on the black cell? Imagine the crossword is so large that it doesn't fit on the canvas, and so the script scrolls the canvas around as the user tabs from cell to cell. Now what happens when the user moves AT focus to a black cell that isn't currently being rendered? Do we have some way to find out that a region is being AT focused? What happens if the keyboard focus and the AT focus get so far from each other that we can't render both at the same time? Which should we be rendering? How do native apps handle these cases? -- Ian Hickson U+1047E)\._.,--,'``.fL
Re: [whatwg] hit regions: limited set of elements for fallback content
On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson i...@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? Whether or not we think it's a good idea, people are building entire UIs using canvas. Sometimes it's in order to achieve pixel-perfect rendering accuracy across browsers and platforms, sometimes it's for speed, sometimes it's for visual effects that aren't possible in HTML, sometimes it's because they're building a cross-platform UI. Asking web developers not to build UIs in canvas is like asking Windows, Mac, iOS, or Android developers to not build custom controls. It's not going to happen. Some developers are going to reinvent the wheel poorly when they should be leveraging the appropriate native controls. But some of the best developers are going to build a fantastic custom control using more low-level primitives because they can make something more awesome - and it should be possible to make that accessible too. Right now, this is intentionally not possible, since it seems that if you want a select, you really should be using a select, not a canvas. What if I do want a select, but I just want a canvas to render it visually? But if there's a valid reason to have a list box or other select control in a canvas, then we should examine that reason and see what precisely is needed to make it possible. (It's probably a lot more than just exposing a select, since you'd need some way to map the open select popup's focus to canvas, and there's no API to do that currently.) Agreed about the open select, which is why I was thinking about the subset of cases that could work - like a select that doesn't open but just lets you change its value with up/down buttons or with arrow keys. What about a list box using ARIA instead? canvas div role=listbox div role=option tabindex=0First option/div div role=option tabindex=-1Second option/div div role=option tabindex=-1Third option/div /div /canvas Why would you use divs in the canvas fallback? Just use the real control, like a select. Because when I do it this way, I can make each (visible) option a hit region, rather than the entire control being one hit region. No, canvas would be a disaster for implementing a spreadsheet. You'd have all of the problems already described for text controls: Yes, but people are implementing text controls in canvas too. We can't ignore that. How about a crossword puzzle game as a more realistic example, where the author wants to draw the whole puzzle in a canvas, not put a canvas inside each cell? Why would you use a canvas for a cross-word puzzle, rather than a table? Games like tic-tac-toe, chess, or reversi would also be reasonable use-cases to consider for this. For 2D versions, why wouldn't you use a table? I don't understand what the cavnas is bringing to the table here. I think that's the wrong question to ask. Lots of people have already made versions of these game using canvas. I don't accept that we shouldn't allow for accessibility because they shouldn't have used canvas in the first place. People are using canvas for all sorts of things. But ok, let's look at a 2D grid like chess or a cross-word. What would you actually need to make that work? canvas table onkeypress=handleKeyInput tr td tabindex=0 I td tabindex=0 N tr td tabindex=0 F td class=black aria-readonly=false /table /canvas What happens if the user navigates the table with their AT and moves the AT focus to the fourth cell? It's not focusable, but do we still need to be telling the AT where the cell is? What happens if we haven't told it where the cell is? That's a perfectly valid question. That suggests we also need a lower-level API that associates an element in fallback content with a region in canvas, even without making it a hit region. I don't see how that's an argument against hit regions, though. If a web author only had the proposed addHitRegion API available, they would have several options available. One would be to simply not represent non-focusable content in the fallback content. Another would be to give those items tabindex=-1 and allow all users to focus them but keep them out of the tab order. Finally another option would be to keep those cells in the fallback content but not map them to their correct path in the canvas, so magnifier users might get temporarily lost. Where is the keyboard focus while the AT focus is on the black cell? This is no different for a canvas or anything else - AT focus can be on any element, focusable or not. Imagine the crossword is so large that it doesn't fit
Re: [whatwg] hit regions: limited set of elements for fallback content
On Tue, 18 Feb 2014, Rik Cabanier wrote: Why would you use a canvas for a cross-word puzzle, rather than a table? Because it is easier to code a nice interface. See this Google doodle: http://www.google.com/logos/2013/crossword/crossword13.html It's fully keyboard navigable but inaccessible since the grid is drawn with canvas. I don't see anything there that really needs canvas. In fact, it seems like it would be substantially easier to implement without canvas. But it is a good example of why we need to answer the questions in my last e-mail before we can properly support it: What happens if the user navigates the table with their AT and moves the AT focus to the fourth cell? It's not focusable, but do we still need to be telling the AT where the cell is? What happens if we haven't told it where the cell is? Where is the keyboard focus while the AT focus is on the black cell? Imagine the crossword is so large that it doesn't fit on the canvas, and so the script scrolls the canvas around as the user tabs from cell to cell. Now what happens when the user moves AT focus to a black cell that isn't currently being rendered? Do we have some way to find out that a region is being AT focused? What happens if the keyboard focus and the AT focus get so far from each other that we can't render both at the same time? Which should we be rendering? How do native apps handle these cases? This example actually adds more questions: How do we handle the multiple focus case? (There's focus in the crossword and in the clue list at the same time.) Do we expose the way each cell can be focused in two different directions? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hit regions: limited set of elements for fallback content
On Tue, 18 Feb 2014, Dominic Mazzoni wrote: On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson i...@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. Whether or not we think it's a good idea, people are building entire UIs using canvas. Sometimes it's in order to achieve pixel-perfect rendering accuracy across browsers and platforms, sometimes it's for speed, sometimes it's for visual effects that aren't possible in HTML, sometimes it's because they're building a cross-platform UI. Just because people do it doesn't mean we need to design our APIs around it, or otherwise endorse it. For example, people use table elements for layout purposes, but this is expressively against the table conformance requirements. People use blockquote for indenting, but instead of providing a blockquote indent-depth attribute, we improve CSS to support indenting. And so on. Asking web developers not to build UIs in canvas is like asking Windows, Mac, iOS, or Android developers to not build custom controls. It's not going to happen. Sure, but that misses the point a little. We are developing technologies for custom controls -- Web components. To support a select drop-down, you need much more than just a canvas: you need a way to show a popup window, you need a way to draw shadows over underlying content, etc. So this is why I ask for the precise use cases. We can only evaluate if the technologies are actually addressing needs by going through and seeing how they do with precise use cases. If the use cases are very vague, we can at best guess, and we might guess poorly. 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. But if there's a valid reason to have a list box or other select control in a canvas, then we should examine that reason and see what precisely is needed to make it possible. (It's probably a lot more than just exposing a select, since you'd need some way to map the open select popup's focus to canvas, and there's no API to do that currently.) Agreed about the open select, which is why I was thinking about the subset of cases that could work - like a select that doesn't open but just lets you change its value with up/down buttons or with arrow keys. Well we wouldn't want to expose a non-multiple size=1 select in the canvas fallback for that kind of thing, because such a select allows you to do things like open the popup, and then we'd be in a horrible situation for AT users (and indeed keyboard users), where you could be navigating something you can't see, the AT would be describing things that don't match the screen, and the script would have no idea what was going on. If what you wanted was just a series of menu items to cycle through, you can do that with addHitRegion() pretty easily. That's just the menu item case I described earlier. What about a list box using ARIA instead? canvas div role=listbox div role=option tabindex=0First option/div div role=option tabindex=-1Second option/div div role=option tabindex=-1Third option/div /div /canvas Why would you use divs in the canvas fallback? Just use the real control, like a select. Because when I do it this way, I can make each (visible) option a hit region, rather than the entire control being one hit region. Why wouldn't you just use select and option? If we want to support list boxes in canvases (which is unclear to me; I don't understand what the use case is), I don't think it would make sense to support it with divs when we have a perfectly good control for it already. No, canvas would be a disaster for implementing a spreadsheet. You'd have all of the problems already described for text controls: Yes, but people are implementing text controls in canvas too. We can't ignore that. We shouldn't ignore it; we should provide better solutions that make it so they don't feel the need to do it. 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
Re: [whatwg] hit regions: limited set of elements for fallback content
On Tue, 18 Feb 2014, Dominic Mazzoni wrote: On Tue, Feb 18, 2014 at 11:39 AM, Ian Hickson i...@hixie.ch wrote: This example actually adds more questions: How do we handle the multiple focus case? (There's focus in the crossword and in the clue list at the same time.) I don't think multiple things are focused at once. Rather, certain composite controls have a notion of which cell is active, that becomes the focused cell when you focus it. If you have a select multiple control on your page, you can tell which items are selected even when it isn't focused, and I think this is the same thing. Yeah, it's not clear exactly what is focused, per se. It could be the cell, or it could be the clue. I'm not sure how to tell. Tab jumps through the clues, the arrows keys jump through the cells. Clicking either has the same/equivalent effect. Both need to be called out when you focus either. Do we expose the way each cell can be focused in two different directions? I don't see how that would translate into an accessibility API, even in a native app. I think the author would have to semantically convey that via some other means. Right, but, what other means? That's what I'm trying to work out. How would we actually solve this specific use case? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hit regions: limited set of elements for fallback content
On Mon, 17 Feb 2014, Rik Cabanier wrote: The current spec for hit regions restricts what elements can be used as fallback content [1]: [...] Why is there this limitation? It supports the content model restrictions, which are there to avoid authors making mistakes that harm accessibility (amongst other things). Reasons for content model restrictions are discussed in more detail in the introduction to the spec: http://whatwg.org/html#restrictions-on-content-models-and-on-attribute-values If there are specific use cases that can't be done given the current restrictions, please let me know; we can definitely consider relaxing some of the restrictions. (It's very hard to tighten restrictions, but comparatively easy to relax them, which is why we start them on the strict side rather than on the relaxed side.) So far, all the use cases that people have brought up for things that can't be done within the current restrictions also happen to be things that canvas is actually really bad at doing at all. There's another non-normative section that goes into more detail about these kinds of things: http://whatwg.org/html#best-practices -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hit regions: limited set of elements for fallback content
On Mon, Feb 17, 2014 at 8:20 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 17 Feb 2014, Rik Cabanier wrote: The current spec for hit regions restricts what elements can be used as fallback content [1]: [...] Why is there this limitation? It supports the content model restrictions, which are there to avoid authors making mistakes that harm accessibility (amongst other things). Reasons for content model restrictions are discussed in more detail in the introduction to the spec: http://whatwg.org/html#restrictions-on-content-models-and-on-attribute-values If there are specific use cases that can't be done given the current restrictions, please let me know; we can definitely consider relaxing some of the restrictions. (It's very hard to tighten restrictions, but comparatively easy to relax them, which is why we start them on the strict side rather than on the relaxed side.) So far, all the use cases that people have brought up for things that can't be done within the current restrictions also happen to be things that canvas is actually really bad at doing at all. Thanks. Were those use cases posted to this list? So, you wouldn't want the same limitations as for regular HTML elements? http://www.whatwg.org/specs/web-apps/current-work/#wai-aria The canvas fallback content could be what is exposed to the user so it might be painful for the author to match it up with hit regions. I agree that relaxing it to any element could allow non-sense. Is there a clear definition of what is disallowed or allowed in HTML? I couldn't find it in the spec. There's another non-normative section that goes into more detail about these kinds of things: http://whatwg.org/html#best-practices
Re: [whatwg] hit regions: limited set of elements for fallback content
On Mon, Feb 17, 2014 at 8:20 PM, Ian Hickson i...@hixie.ch wrote: If there are specific use cases that can't be done given the current restrictions, please let me know; What about select? What about an element with a tabindex and an ARIA role that corresponds to a control? Note that there are a few ARIA roles for interactive controls that don't have matching HTML counterparts, like gridcell, menuitem, or spinbutton.
Re: [whatwg] hit regions: limited set of elements for fallback content
On Mon, 17 Feb 2014, Rik Cabanier wrote: Were those use cases posted to this list? I'm sure some were. Your typical use case would be something like a graph, a game menu, a fractal explorer, and so on. So, you wouldn't want the same limitations as for regular HTML elements? Not sure what you mean. The rules for addHitRegion() match the regular canvas content model. http://www.whatwg.org/specs/web-apps/current-work/#wai-aria This seems orthogonal to the issue of addHitRegion()... I'm not sure I follow the relevance here. The canvas fallback content could be what is exposed to the user so it might be painful for the author to match it up with hit regions. Not sure what you mean here. Can you elaborate? Maybe an example would help. I agree that relaxing it to any element could allow non-sense. Is there a clear definition of what is disallowed or allowed in HTML? I couldn't find it in the spec. Allowed or disallowed in what sense? If you mean the content models, the specification has elaborate text describing the rules; you can find the introduction to content models here: http://whatwg.org/html#content-models -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hit regions: limited set of elements for fallback content
On Mon, 17 Feb 2014, Dominic Mazzoni wrote: On Mon, Feb 17, 2014 at 8:20 PM, Ian Hickson i...@hixie.ch wrote: If there are specific use cases that can't be done given the current restrictions, please let me know; What about select? What about it? What about an element with a tabindex and an ARIA role that corresponds to a control? Can you elaborate? Note that there are a few ARIA roles for interactive controls that don't have matching HTML counterparts, like gridcell, menuitem, or spinbutton. Sure. addHitRegion() supports roles like menuitem this in two ways: If you're doing something like a straight-forward menu item, you can just add the text and the role directly. If you're doing something more elaborate (e.g. a menu with disabled items), you can add appropriate elements (e.g. button) representing the menu into the canvas fallback content, and use ARIA roles and properties to override button's defaults. Once you get to more elaborate compound controls like spin buttons, you really shouldn't be using canvas in the first place, and so those aren't supported (spinbutton in particular would be impossible to correctly support in a canvas, since it's a compound control with multiple subregions, all corresponding to a single DOM node on the ARIA side). Simple grids are supported the same way that simple menuitems are supported; again, though, once you get to elaborate grids with cells that can be marked invalid, marked as having popups, etc, you really shouldn't be using canvas, so those aren't supported. That's what table is for. If you want a table with graphics inside, the way to do that is to have a table with each td containing a canvas, not a single canvas. This is relatively important because users really don't want authors reimplementing table navigation themselves -- indeed I'm not even sure it's technically possible for an author to track the AT focus as the user navigates a table using AT commands, so it would be incredibly difficult for an author to do a good reimplementation of a grid on canvas. If there are specific use cases for why you'd want to recreate a table using canvas, please do describe it. If we need to support this, then we should make sure we do a good job (as noted, the current APIs aren't sufficient, even if we just make addHitRegion() support pointing to td elements in the canvas fallback content). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
