RE: consideration for SVG 1.2

Thanks for the support - and great examples.
As for the styling example, the point was
to resolve via the externalResourcesRequired
attribute. Some of our platforms may not fully
implement available features. We would like
the ability to offer alternatives w/o creating
distinct document sets for each platform. My
other point was to make sure that the switch
resolved to something acceptable to SVG
text when the switch is referenced by a tref.
The current behavior, as you demonstrated,
is fairly inconsistent and perhaps needs
further specification.

Thanks again.

-----Original Message-----
From: Doug Schepers [mailto:doug@schepers.cc]
Sent: Friday, July 16, 2004 5:06 AM
To: 'James Bentley'; 'Robin Berjon'; www-svg@w3.org
Subject: RE: consideration for SVG 1.2


Hi, folks-

Comments inline: 

James Bentley wrote:
| 
| 
| Comments below.
| 
| Robin Berjon wrote:
| 
| James Bentley wrote:
| > Please consider allowing 'tref' elements to reference 
| 'switch' elements.
| Our
| > current product has a need to provide conditional text based on 
| > resources available on the platform (i.e. 
| > 'externalResourcesRequired'). In this manner, we can support our 
| > conditional text insertion, and inherit the proper styling.

I'm not sure that this is a good idea. What if the content you are accessing
is not SVG, but some arbitrary XML? Also, when I have used 'tref' in the
past, I explicitly wanted to style it in situ, so unless you could override
any style properties that you "inherit" from the reference, this could be
troublesome; even then, you'd have to know exactly which style attributes to
override, or override them all explicitly. 

I don't know your exact use case, but couldn't this be handled in the
authoring? For instance, if you knew that certain text needed to be colored
red, for a warning, do something like this (pseudocode):

<svg id='source'>
   <text id='standard1'>This is a new message</text>
   <text id='standard2'>We have had reports that the mole people have been
spotted in Schenectady.</text>
   <text id='standard3'>Stand by for further news.</text>

   <text id='warning1'>Important!</text>
   <text id='warning2'>Do not approach them. They are smelly, and are known
to bother "Upworlders" for money and try to sell shoddy watches.</text>
   <text id='warning3'></text>
</svg>


<svg id='target'>
   <text id='standard1'>
      <tref id='header' fill='black' font-weight='bold'
         xlink:href='source.svg#standard1' />
      <tref id='disclaimer' fill='crimson' font-style='italic'
         xlink:href='source.svg#warning1' />
      <tref id='mainBody' fill='black' 
         xlink:href='source.svg#standard2' />
      <tref id='inlineWarning1' fill='red' 
         xlink:href='source.svg#warning2' />
      <tref id='secondBody' fill='black' 
         xlink:href='source.svg#standard3' />
      <tref id='inlineWarning2' fill='red' 
         xlink:href='source.svg#warning3' />
   </text>
</svg>

| In SVG 1.1 tref can reference *any* element, and its full 
| textual content will be used (without the markup). I assume 
| that what you want is for switch to do its conditional 
| processing before tref does its inclusion, otherwise you get 
| all of switch's content, right?
| 
| [James Bentley]  Yes, that would be desirable. However, I 
| would feel more comfortable if tref elements could only 
| reference elements that resolve to text. This does assume 
| that the resolution can be made before the tref element is bound.

I agree with James that this would be a Good Thing. And I can even suggest
how this might be differentiated: allow 'trefs' that point to the 'switch'
element to get only that content that the switch passes through. References
to 'text'-type elements (or other XML) would still resolve to whatever
content that tag contains, in its entirety.
Please see the source for this file for details:
http://www.schepers.cc/testbed/text/tref/trefTestExternalSwitch.svg

This brings up another issue I have with 'switch':
why not allow it to be the child of a 'text' element, and switch on child
'tspan' elements? As you can see from the source above, it would be sensible
in terms of saving duplicated effort, especially once we have flowing text,
to allow for switching just on the text content, not on the whole
positioning and styling structure for that text. Also, it causes a
potentially confusing duplication of the id attribute among the switch
options, as is.


Regards-
-Doug

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.719 / Virus Database: 475 - Release Date: 7/12/2004

Received on Friday, 16 July 2004 10:36:22 UTC