W3C home > Mailing lists > Public > www-svg@w3.org > September 2005

RE: Switch and Feature Strings

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>
Message-Id: <20050929031706.DD7CC12DA0C@pilfer.dreamhost.com>

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?
 <g requiredFeatures='...Text' requiredFeatures='...Strokes' />  
...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.


doug . schepers  @ vectoreal.com
www.vectoreal.com ...for scalable solutions.
Received on Thursday, 29 September 2005 03:17:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:04 UTC