RE: Switch and Feature Strings

Robin!!!!

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

In my opinion, the element and its core attributes.


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

Er. Um.... (Schepers takes a crash course in reading English...)

But really, I guess I mean that to say, doesn't that suffice for the
combinations that you spoke of? You don't need to have every combination as
a string, you just need a combinatorial mechanism. That is, you don't need
to define "a+b", you just need to allow the "a+b" combination. Which you do.
Which is good. But not at the element level, only at the module level
(which, for text at least, doesn't seem fine grained enough... Anyway, for
the purpose of feature strings, modules are just collections of elements, it
seems to me).


| > 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 :)

Hey, I don't want you straining your pointy lil heads with anything
difficult... ;) But really, I meant it from both perspectives. I honestly
don't know how hard it is to implement.


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

Yeah, but a clever imp would just check the feature string against the
elemental tokens it is using to parse.
 

| 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 :)

I think it would be easier to keep track if you only had to provide it for
element-level, rather than module-level features. But that's just me.

Honestly, it's not a big deal. I was originally just wondering if I was
getting it wrong, because it seemed intuitive to me that I could check for a
elemental support, in the same way that I can manually check an imp's
release notes for such support. If people think it's good enough as it
stands, I'm happy to close the thread.


Regards-
Doug

doug . schepers  @ vectoreal.com
www.vectoreal.com ...for scalable solutions.

Received on Thursday, 29 September 2005 10:12:02 UTC