- From: Danny Ayers <danny666@virgilio.it>
- Date: Tue, 19 Mar 2002 00:30:47 +0100
- To: "Chris Lilley" <chris@w3.org>
- Cc: "'Www-Svg" <www-svg@w3.org>, "W3c-Wai-Ig" <w3c-wai-ig@w3.org>
Hi Chris, >DA> Has anyone played with stylesheets to render SVG data down to >good ol' html >DA> image maps? > CL>That would seem problematic in the general case. Very true. >DA> Whilst looking at some XSLT that went the other way around >[1], it occurred >DA> to me that this might be useful in situations where an SVG >viewer wasn't >DA> available > CL>Rendering of static images is fine, for such situations, but I would CL>be reluctant to go too far down the imagemap /sliced table / ton of CL>javascript route because it dumbs down what SVG is capable of and, if CL>lots of effort is put into it, merely delays the general rollout of CL>SVG. And the result tends to be wildly inaccessible, slow, heavy, and CL>of poor quality. Urrgh! I certainly didn't have a ton of Javascript in mind. Or a ton of effort. Image maps may be slow, heavy & poor quality, but on a browser that doesn't support SVG they are at least visible. I personally would prefer the rollout of SVG to be as quick as possible, and something like this might even encourage SVG uptake as the source format would be SVG, though realistically I doubt whether it would make any difference one way or another. >DA> and/or there was an assistive technology that could make some >DA> sense of an image map but would baulk at SVG. > CL>That seems unlikely, and contrary to UAAG guidelines. A real, CL>interoperable XML DOM is a far better bet for an assistive technology CL>that either screenscraping or a problematic and browser-dependent, CL>undefined, 'HTML DOM Level 0'. I must re-read the guidelines. A real, interoperable XML DOM is a good aim (for the present) I agree, I just thought this might be a simple pragmatic approach to make some material more available. Forget I mentioned it ;-) Cheers, Danny.
Received on Monday, 18 March 2002 18:35:15 UTC