The point of that restriction is that you shouldn't try to re-implement <input type=text> or <select> in <canvas> at all.

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?

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.

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.

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.

(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?

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?

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

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

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.

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.

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