Re: Switch and Feature Strings

Hi Doug!

Doug Schepers wrote:
> | 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.

What do you call "implementing an element" (I'm not being rhethoric, 
just curious)? Is it the element and its core attributes, or the element 
and the properties that are relevant to it?

> | 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...

Dude, why do you think there's an 's' at the end of that attribute name? :)

"The value is a list of feature strings, with the  individual values 
separated by white space. "

So yes it can be authored that way, but it may get rather painful to 
author really.

> | 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.

Thanks for thinking first of your poor WG members toiling about the spec 
day and night by proposing a way in which this change could be effected 
with minimal editing :) However it also complicates implementation to a 
degree (for almost every change to have to check whether it validates a 
feature string), it potentially leads to very hard to read content, and 
the number of strings can become quite noticeable in the codesize for a 
mobile implementation.

Those are not strong objections, but I am generally concerned about 
feature string creep. Keep in mind that your problem originially stemmed 
from Mozilla claiming to support the Text module when it only support 
BasicText. If implementers find it hard to keep their feature strings 
list up to date with the current list, adding more isn't going to help :)

-- 
Robin Berjon
   Senior Research Scientist
   Expway, http://expway.com/

Received on Thursday, 29 September 2005 09:51:34 UTC