14419 2011-10-10 23:21:12 +0000 when canvas isn't supported, or for blind users, the canvas element's content should be displayed, so excluding input types like text and select is discriminatory 2012-11-15 21:35:50 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified Other other CLOSED WONTFIX http://www.whatwg.org/specs/web-apps/current-work/#the-canvas-element a11y, a11ytf, a11y_canvas P3 normal --- 1 contributor ian cooper franko ian jackalmage jsalsman laura.lee.carlson lwatson mike public-html-a11y public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 58016 0 contributor 2011-10-10 23:21:12 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html Multipage: http://www.whatwg.org/C#the-canvas-element Complete: http://www.whatwg.org/c#the-canvas-element Comment: when canvas isn't supported, or for blind users, the canvas element's content should be displayed, so excluding input types like text and select is discriminatory Posted from: 67.6.175.132 User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.202 Safari/535.1 58017 1 jackalmage 2011-10-11 00:08:34 +0000 The point of that restriction is that you shouldn't try to re-implement <input type=text> or <select> in <canvas> at all. 58021 2 jsalsman 2011-10-11 00:36:06 +0000 Tab, as I understand the situation, the content of the canvas element is displayed as an alternative when the canvas element can not or should not be displayed. Forbidding an arbitrary set of elements disadvantages those who do not have canvas support or eyesight. What does forbidding such elements do to prevent reimplementable of them in Canvas? If there is a canvas application which allows sighted people to paint a picture but people without canvas support or eyesight to provide text instead, there is no reason to forbid that, is there? 58024 3 jackalmage 2011-10-11 00:50:47 +0000 No, it doesn't disadvantage anyone, because those types of inputs should just be handled as normal HTML. It's practically impossible for web devs to actually implement the equivalent to <input type=text> in canvas. That little element has massively complicated interactions with lots of things, and is still sometimes buggy in the details in modern browsers which have had tens or hundreds of browser-dev-hours devoted to working on it. If a drawing application is implementable in text, it's almost certainly going to be a bad experience if the text-based editor is running at the same time as the canvas-based editor. If it *can* be run at the same time (say, perhaps it's just a REPL-like interface to the canvas), then it's not fallback, it's an alternative input method that can be useful to sighted users as well. 58026 4 franko 2011-10-11 02:13:08 +0000 Splitting the OR and addressing the two statements: "when canvas isn't supported - the canvas element's content should be displayed, so excluding input types like text and select is discriminatory" If the UA doesn't support canvas, the 'fallback' content is displayed. At the moment there is nothing in the spec that prohibits authors from adding input type=text in this scenario; but I would imagine that they would create the same solution for non-canvas UAs and a11y fallback content scenarios. "For blind users - the canvas element's content should be displayed, so excluding input types like text and select is discriminatory" As Tab points out, recreating text editing in canvas is not possible; the author would not be able to recreate all the features on the UA's platform that aid text entry/editing. Limiting input type=text in this scenario makes sense, as we don't want authors created halfbaked solutions where better alternatives are clearly available. FWIW I have not seen any projects where authors are recreating text input/editing with canvas. 58027 5 jsalsman 2011-10-11 03:11:00 +0000 Why do people think this has anything to do with reimplementing forms with canvas? The issue here is that sometimes a canvas will be unavailable or unusable, and in that case, why would you want to forbid a form asking for an email address or selecting from a list? I agree that implementing forms with canvas is a bad idea, but removing legitimate functions that would help the blind and people on text mode browsers is not going to do a thing to make that less likely. This is like building a fence around the tractor shed to keep the cows in the barn. 58030 6 jackalmage 2011-10-11 04:18:33 +0000 (In reply to comment #5) > Why do people think this has anything to do with reimplementing forms with > canvas? > > The issue here is that sometimes a canvas will be unavailable or unusable, and > in that case, why would you want to forbid a form asking for an email address > or selecting from a list? A canvas can't be "unavailable". When a canvas is unusable, the fallback content is meant to represent the same thing as the canvas. How is a text input in the fallback supposed to represent anything on the canvas other than a canvas-implemented text input? 58056 7 jsalsman 2011-10-11 15:48:33 +0000 In a text mode browser or a browser with images disabled due to user option selection or prohibitively low bandwidth, the canvas is technically usable but unavailable. It is available but unusable for the blind. > When a canvas is unusable, the fallback content is meant > to represent the same thing as the canvas. Where are you reading that? It's mistaken. > How is a text input in the fallback supposed to represent anything > on the canvas other than a canvas-implemented text input? For example, suppose a custom bookcase vendor asks customers to sketch their wall and neighboring furniture configuration and locations of wall studs on a canvas element. Can you think of any better fallback content than a form for their phone number and/or email so that they might be contacted by a designer? 58058 8 jackalmage 2011-10-11 16:09:56 +0000 (In reply to comment #7) > > When a canvas is unusable, the fallback content is meant > > to represent the same thing as the canvas. > > Where are you reading that? It's mistaken. The spec. <http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#the-canvas-element> "When authors use the canvas element, they must also provide content that, when presented to the user, conveys essentially the same function or purpose as the bitmap canvas. This content may be placed as content of the canvas element. The contents of the canvas element, if any, are the element's fallback content." 58061 9 jsalsman 2011-10-11 16:25:36 +0000 > "When authors use the canvas element, they must also provide content that, when > presented to the user, conveys essentially the same function or purpose.... I see; "essentially the same purpose" is not "the same thing". Please make the change. 58679 10 ian 2011-10-21 22:55:07 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: It can't be "the same thing", since the "same thing" would be a picture, and the whole point of the fallback is to not display a picture. 61606 11 mike 2011-12-15 16:30:00 +0000 We discussed this on the the a11y TF call this week and we believe this bug looks like it is related to issue 131 or duplicating it. 78374 12 lwatson 2012-11-15 21:35:50 +0000 Comment via Rich Schwerdtfeger: This text exists in the canvas element specification: "When authors use the canvas  element, they must also provide content that, when presented to the user, conveys essentially the same function or purpose as the bitmap canvas. This content may be placed as content of the canvas  element. The contents of the canvas  element, if any, are the element's fallback content."