Re: Hit testing use cases Re: Request to re-open issue 131

In the spirit of good discussion I'm going to ask that people refrain from describing the development of text entry tools in Canvas as "foolish". It's been publicly framed as such by several developers including the HTML5 editor. It's widely known that I've created several text editing implementations, as have some of my peers. I find these remarks disparaging and without technical merit.

iOS Mobile Safari does not implement contentEditable yet Canvas RTE works on the platform. Authors have been creating text widgets since GUIs first allowed them to. There's nothing taboo in the desktop realm about text editing.

All vendors found a big leap up in using their own (or new) rasterization techniques. Software code is not magical, there is no reason that custom UI components ought to be treated as taboo.

If I see this kind of talk again, I will refer to the W3C discussion guidelines.

I've repeatedly stated that rich text entry is not the reason why I'm advocating that the Canvas sub-DOM be supported. ARIA and Semantic HTML are the reason. I've repeatedly linked to system accessibility APIs and named AT software which requires those APIs to function.

I've done my part in good faith. I'm requesting that vendors show more respect to the process of Canvas UI development these discussions.

-Charles


On Dec 18, 2011, at 8:44 AM, "Charles McCathieNevile" <chaals@opera.com> wrote:

> I also believe that building text editors in canvas is a fool's errand, but that hit testing with a level of "what pixel was touched" would be valuable.

Received on Sunday, 18 December 2011 17:26:59 UTC