- From: Leif Halvard Silli <lhs@malform.no>
- Date: Sun, 22 Mar 2009 19:52:54 +0100
- To: "John Foliot - WATS.ca" <foliot@wats.ca>
- CC: 'Charles McCathieNevile' <chaals@opera.com>, 'John Foliot' <jfoliot@stanford.edu>, 'Wai-Ig' <w3c-wai-ig@w3.org>, wai-xtech@w3.org, 'HTMLWG' <public-html@w3.org>, 'WebAIM Discussion List' <webaim-forum@list.webaim.org>, 'Gawds_Discuss' <gawds_discuss@yahoogroups.com>
John Foliot - WATS.ca 2009-03-21 23.24: > the specification now insists, in the strongest language > available to specification writing, that the <canvas> element > contain ‘fallback’ content for users who cannot consume the > intended ‘thing’ that <canvas> is delivering. > But one thing remains hotly contested, and that is my > suggestion for what to do when <canvas> (and other HTML > elements) is/are non-conformant? > how are [authors] to be sure that what they build will always > work? Bloat out browsers with ‘error-recovery’ code, or simply > insist that they get it right per the specification and send > them back to the drawing board when they don’t? > > If not critical failure, then what? It is easier for authors to check whether one used <canvas> correct, than it is to check whether one used <object> correct. It only takes that one to turns off JavaScript - confer the draft: "In non-visual media, and in visual media if scripting is disabled for the canvas element, the canvas element represents its fallback content instead." What additionally could we do? We could look at validators: The draft now has quite meticulous explanations about how the @alt attribute is to be used. Where are the rules and advice for how to add fallback in general? Does validators warn for <object> and <canvas> without fallback? -- leif halvard silli
Received on Sunday, 22 March 2009 18:53:46 UTC