- From: Charles Pritchard <chuck@jumis.com>
- Date: Fri, 08 Jul 2011 13:54:33 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: John Foliot <jfoliot@stanford.edu>, Jonas Sicking <jonas@sicking.cc>, public-canvas-api@w3.org, public-html@w3.org, public-html-a11y@w3.org
On 7/8/2011 1:14 PM, Tab Atkins Jr. wrote: >>> >> "rich text editing" >>> >> I think that the only good solution here is to severely improve >>> >> contentEditable. Currently contentEditable is a pain for authors to >>> >> use because it doesn't provide a low level API, only high-level things >>> >> like execCommand. It also works dramatically different in different >>> >> browsers and with lots of different bugs in all browsers. It's really >>> >> quite terrible. It's not surprising that some developers have said >>> >> "screw it" and attempted to do better using canvas. >> > >> > And it seems then that this is a major itch that needs scratching right >> > now - certainly not the only one, but a really big one. The fact that "... >> > some developers have said "screw it" and attempted to do better using >> > canvas" is the very reason why telling them "don't do it" has very little >> > traction - they don't have other choices right now. So faced with this >> > truth, the canvas accessibility folks are attempting to develop an >> > "ARIA-like" solution: sure it seems bolt-on, more complex, less elegant, >> > less intuitive... but solving the problem that needs to be solved, and >> > hopefully in a framework type of way that can be used for the next >> > unimagined cool thing in<canvas>. > First, high-profile attempts to say "screw it" and do better with > canvas have failed, precisely because it's very hard to do. It's > simply not feasible to do this sort of thing well. People will > continue to try, and they'll likely continue to fail. My attempt did not fail; I created a more dynamic and flexible contenteditable area, and I even mark it up as contenteditable. PDF.js has not yet "failed", though they're in for a rough time bringing their issues forward. They're lucky to have a more welcome reception than other labs teams. Bespin was a Mozilla labs project; Mozilla proper got upset about it. I've experience Mozilla proper's wrath. It sucks, it's not based on pragmatism, but it is based on an idealism about protecting the end user. It's the same idealism that shouted down my efforts to fix issues with pixel resolution. I have to use 20 lines of CSS code because they are intentionally making things difficult. That's very much like your comment of things should be "painful". The failure of Bespin was a not failure of technology, it was a failure of corporate communication. Mozilla labs is out there on the side, they brought in something that the corporation strongly disagreed with and it was subsequently axed. It happens all the time with labs projects.
Received on Friday, 8 July 2011 20:55:09 UTC