- From: Doug Schepers <doug@schepers.cc>
- Date: Wed, 28 Sep 2005 23:17:00 -0400
- To: "'Robin Berjon'" <robin.berjon@expway.fr>, "'Chris Lilley'" <chris@w3.org>
- Cc: "'www-svg'" <www-svg@w3.org>
Hi, Robin- Thanks for your reply. | Digging further, the problem with trying to produce the level | of granularity that Doug is looking is knowing where to stop. Yes, I can definitely see that point of view. | Every element and every attribute and property is going to | make for a large list already, I think that it is a very realistic view to allow element-level switching. As implementations (for instance, Firefox) grow, they are going to have many missing elements. For authors, it is good to allow for fallbacks as we have to deal with multiple UAs. | and combinations thereof | (which may be meaningful, eg stroked text, or even just | stroked text on bitmap fonts) even more. Can't this be solved by allowing more than one feature string to be tested? <switch> <g requiredFeatures='...Text' requiredFeatures='...Strokes' /> </switch> ...or something... | The current limit | set at modules plus specific features that we know may cause | trouble in some situations (eg transformed or composited | video on mobile devices) is imho the most reasonable, but maybe | other people here will have better suggestions. What's the overhead in a large numer of requiredFeature Strings? In the Spec, it could just be stated that any element name is a potential string. Regards- Doug doug . schepers @ vectoreal.com www.vectoreal.com ...for scalable solutions.
Received on Thursday, 29 September 2005 03:17:18 UTC