I've yet to see anyone respond to the use of touch/ink (such as from a Wacom tablet) in relation to entering content into an input field.
Further, input type=text is the fallback for unsupported input types. Consider input type=search and how that falls back to text. We should not single out nor blacklist textarea, input type=text nor other input fields. I'd rather have DOM/window focus on an HTML input field with appropriate semantics. The alternative is to use ARIA on div/span: that does work, but it seems a disabling limitation to codify into the HTML spec. -Charles On Aug 8, 2012, at 1:29 PM, Frank Olivier <[email protected]> wrote: > "it seems like quite a few other elements are reasonable candidates for hit > targets." > > I agree - I don't think the whitelist is a good idea either. With the > exception of <input type='text'>, most DOM elements would be a valid choice. > > From: Maciej Stachowiak [mailto:[email protected]] > Sent: Monday, July 30, 2012 12:43 AM > To: Charles Pritchard > Cc: Richard Schwerdtfeger; Edward O'Connor; Steven Faulkner > ([email protected]); Frank Olivier; Michael(tm) Smith ([email protected]); > Paul Cotton; Philippe Le Hegaret ([email protected]); Sam Ruby > ([email protected]); [email protected]; [email protected]; > [email protected] > Subject: Re: Discussion on ISSUE-201: canvas-fallback > > > On Jul 26, 2012, at 3:22 PM, Charles Pritchard <[email protected]> wrote: > > > On Jul 26, 2012, at 11:56 AM, Maciej Stachowiak <[email protected]> wrote: > > This text needs to be changed to: > > "The arguments object's control member references an element with a valid id." > To add some context to Rich's point (which I did not understand until I read > the full diff text), it appears that hit regions backed by elements are > limited to hyperlinks, buttons, checkboxes and radio buttons. If you specify > any other element, the method will throw an exception. It's not clear to me > why other elements are categorically excluded from backing a hit region. > > > The HTML editor was quite vocal in his opposition to other uses of Canvas in > user interface authoring. The text as available in the CP simply reinstates > the editors changes. > > As a group, the Canvas attendees decided against such restrictions. The HTML5 > Editor did not attend any of these discussions. > > That may explain why in the historical sense, but it does not explain why in > the rationale sense. What I'm suggesting is that the CP should provide > rationale for this restriction if it is maintained, or else drop it. > > To me at least, it seems like quite a few other elements are reasonable > candidates for hit targets. Here are a few use cases that go beyond the CP > but which I expect are uncontroversial: > > <input type=range>: using canvas to make a dial-type range control, to match > the UI idiom of an audio synthezier > <td>: an interactive bar graph where the fallback is a table, and clicking a > column should active code associated with the corresponding table cell > <input type=color>: color picker in a canvas-based paint program > <summary>: for an expandable section of canvas-rendered controls that has the > behavior of <details>; this would need to be clickable and focusable > > The whitelisting of a very limited set of native controls also stands at odds > with allowing any ARIA role whatsoever. > > Those are some reasons why I find this aspect of the CP puzzling. > > Regards, > Maciej > > >
