- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Fri, 17 Jan 2014 17:53:33 +0100
- To: www-svg@w3.org, mcelam@google.com
Miles Elam: >I already have graphical fallbacks to raster graphics if SVG is not >supported. I think, you do not need to do this, if you have alternative text for those SVG documents, that are not only decorative. And if the graphics are only decoration, you need no alternative text both for SVG and for raster images and you do not have to worry about wrong or incomplete display or no display at all ... >The issue at hand is that IE9 and above indeed support SVG; they >simply don't support SMIL. Rather than burden every SVG-capable browser >with 6KB of JavaScript when the original SMIL asset is just over 500 bytes, Well, other viewers have major bugs and gaps as well - unfortunately. It would be already a big progress, if only one viewer had major bugs and gaps ;o) To get replacements for some of them for static files you may get an increase of the file size of some orders of magnitude ... However you should note, that java-script is no alternative or replacement for declarative animation. If script interpretation is switched off, such scripts will not matter for the presentation and they do not matter for content anyway. The script does not really change the meaning of the document, only the appearance. This differs from declarative animation - this really matters for content ;o) As you can see, their is no win in using scripts as an alternative, because it is no alternative. If a viewer does not animate declaratively, there is no equivalent replacement. The audience can only replace the viewer, if it needs to see what is really going on. >I wanted a way to conditionally load the script only when the SMIL features >were missing. From what I'm gathering, this is not possible, and my only >viable options are user agent detection on the server side or a stub >loading script in the SVG. This I understand, sounds like a bug of those viewers if their script interpretation is switched on. Unfortunately there seems to be no method for authors to switch script interpretation off. Just to avoid needless discussions in bug reports to implementors I recommend to send documents that validate. >The accessibility provisions do not apply here as the SVG already has >alternate text. Well, then everyone, at least in theory has access to the content, no need to worry. Because there is no way to work around the gap not to interprete animation for authors, good alternative text seems to be the only way to propagate the content to users of viewers with such major gaps and bugs. >In addition when used as a CSS background image, alt text >becomes moot anyway. The crux of matter is that IE9 and above can do >everything I require, they just require one additional asset to do it—an >additional asset that is 10x larger than the file it acts upon—and I would >prefer not to load in other browsers if I can avoid it. Yet falling back to >descriptive text for all IE versions is completely out of the question as >that would be cutting off my nose to spite my face. Note that according to the draft about 'integration' https://svgwg.org/specs/integration/#static_mode in the future viewers may not apply scripts or declarative animation to CSS background images anyway. Once viewers care about this, there will be no chance to provide non static background images with CSS anyway - what is a little bit surprising, because there are already drafts for CSS animation and there seem to be methods to change the style within the DOM with scripts as well. ;o) Microsoft introduced 'conditional comments' - this might help to provide other stylesheets for specific versions of MSIE to hide bugs of these specific versions of MSIE - did you try this? And as already mentioned - no need for text alternatives for CSS background images - they are only decoration. You can use a simple color as alternative to ensure that there is still enough contrast bet fore- and background. Obviously if the viewer interpretes only parts of an SVG correctly, you may get in trouble with contrast of background to foreground, but due to the 'integration' draft it is better not to rely on animation and scripting in background images anyway. Olaf
Received on Friday, 17 January 2014 16:54:03 UTC