Re: Canvas accessibility discussion on WHATWG IRC

On 11/12/2011 12:41 AM, Steve Faulkner wrote:
> krijnhoetmer.nl/irc-logs/whatwg/20111112
>
> Worth a read,
>
> Apperently hixie doesn't read this list and he has not been presented with any use cases yet.
>
> Sent from my iPhone

Here's a note from what Hixie thinks about his role as a spec editor for 
Canvas 2d:
https://lists.webkit.org/pipermail/webkit-dev/2011-September/018066.html
"the moment I add anything to canvas, everyone implements it, dropping 
whatever else they were working on, and so if I keep adding  canvas 
features nothing else gets done"

Tab Atkins works very closely with Ian and has been presented with a 
long list of use cases. Ian has been presented with many real-world use 
cases in the past.
Like Tab, he often declared them as better served by SVG. "Gaming" seems 
to be the only exception. They both seem to think games are a special case.

In response to Hixie's comments on IRC: many web app developers create 
authoring tools.
"# [00:03] <Hixie> sicking: currently they just hand-wave the use cases 
and then design things that would only make sense if you were doing 
something absurd and cockamamie like implementing a word processor in 
canvas or something  "

There's nothing absurd about creating word processors. I know that 
Microsoft and Adobe have Word and PageMaker and all of that, but there's 
still room in the industry for small coding shops to create utilities, 
such as word processors, vector editors, paint programs and the like. 
We're not restricted to just developing "games". It's not hand-waving 
when there are hundreds of thousands of dollars of investment into 
various utilities. There are millions of users on the web that have 
installed Canvas-based applications. It's already happened. For the past 
few years, many people on public-canvas-api have just been trying to fix 
a bad situation that has already occurred.


In response to waiting for Path objects:
"# [00:09] <Hixie> yeah your proposal is basically what i had in mind, 
except i think we should just do it with Path objects instead of 
continuing to use the existing path stuff".

This in no way changes the proposal. Path objects will help, and that's 
super. But it doesn't change a thing about the setPathForElement proposal.
I've proposed path objects repeatedly on the list. This is fairly simple:
ctx.path(in DOMString); // takes in the SVG path notation d="M...z" .
ctx.path(in CanvasPath);
ctx.createPath() returns CanvasPath representing the current path.

I don't know what Ian is proposing, though he's suggesting it's a 
departure from current path methods:
"everything we add to the existing path stuff will have to be duplicated 
when we add path primitives".

I have no idea why that would be the case. So I'll just have to 
stand-by. Those simple methods and they work
just fine with current proposals.

-Charles

Received on Saturday, 12 November 2011 17:10:15 UTC