- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 20 Jan 2010 13:33:35 -0800
- To: Steven Faulkner <faulkner.steve@gmail.com>
- Cc: Ian Hickson <ian@hixie.ch>, public-canvas-api@w3.org, HTML WG <public-html@w3.org>
On Jan 20, 2010, at 4:52 AM, Steven Faulkner wrote: > hi maciej, > > >If you're using the contained DOM children as a model/controller in this way, then indeed, it's not just 'fallback'. It becomes a way of building your application >logic in a way that also makes it very easy to expose to assistive technologies. Doing it that way is an option, however, not a technical requirement. You >could just as easily just assign window.location to navigate, in this example. > yes i understand that it is not a requirement nor was i suggesting it should be. I was/am trying to undertsand the mechanics of the relationship between the focus rectangle and the canvas sub dom. Though I do think it is very useful to know that developers place content in the canvas element and use it to drive interaction on the canvas rather than having to create it all from scratch. > > You could just as easily just assign window.location to navigate, in this example. > > but then you would be doubling up no? one method of triggering the interaction for mouse users and one for keyboard users, seems like a waste of effort? I have no particular judgment on which is the better way to do it, I'm just saying both are possible. > > >If you're using the contained DOM children as a model/controller in this way, then indeed, it's not just 'fallback'. > > so then the definition of what constitutes canvas fallback in the spec needs to change. It might be good to refer to the subdom as something other than "fallback", but I don't have any ideas for a great term, and as it happens it is also what gets displayed in UAs that don't support canvas and have it disabled, which is a more traditional conception of fallback. Regards, Maciej
Received on Wednesday, 20 January 2010 21:34:10 UTC