- From: Matt May <mattmay@adobe.com>
- Date: Wed, 29 Jun 2011 16:30:11 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: "public-canvas-api@w3.org" <public-canvas-api@w3.org>, "public-html@w3.org" <public-html@w3.org>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
-----Original Message----- From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Tab Atkins Jr. > Can we please have a listing of the problems that are attempting to be > solved by the proposals beforehand? It's impossible to evaluate a > proposal without knowing what it's trying to do, and how we'll know > when it's succeeded. It's actually pretty easy to go back into the archives and find the problems that need to be solved. Just search for "canvas 'doing it wrong'". That's been the stock response to every case that can't be explained away easily. (Which is kind of funny when you think about it, since it was a spec that refused to render content to the user due to author error that was responsible for the XHTML->HTML schism in the first place.) You can tell people they're abusing your spec all you like. And I'm sure it will be as great a success as when we all told people to stop using layout tables, and authors everywhere dropped their TRs and TDs immediately and sang Kum Ba Ya together in front of their laptops. No, wait. That didn't happen, did it? People kept on doing what they were doing because they, like browser vendors, have their time and money sunk in code they are reluctant to have to refactor. And so it will be with canvas. The sooner people here realize that "just use SVG" is not a valid solution to all cases, and that that means some kind of model for canvas accessibility is in fact needed to close the gaps (or pave the... how does that go again?), the sooner we can stop beating our heads against this brick wall. - m
Received on Wednesday, 29 June 2011 23:30:44 UTC