RE: separating svg data from presentation

i appreciate the responses to this.  i have a couple more cents to put in...

>From: "Jon Ferraiolo" <jferraio@Adobe.COM>
>
>>From: "Mjumbe Ukweli" <mjumbe@electricstoat.com>
>>
>>>From: "Max Dunn" <maxdunn@siliconpublishing.com>
>>>
>>>[...]Where did you hear it stated that SVG was "concerned with describing 
>>>the geometry of an image, not the color,
>>>etc."?...
>>
>>[...]i would automatically assume that any XML namespace
>>is used to describe data because that's what XML does; each namespace just 
>>has a different type of data to represent.  [...]right there we have our 
>>data: vector shapes, images and text.  [...]now i would say that anything 
>>that is not grouping, transforming, compositing, or describing vector 
>>shapes, images or text would go in the
>>category of style.
>
>With SVG, the question of what is content and what is style gets blurred. 
>There might be multiple versions of a logo, for example, for different 
>styling situations, each with different geometry. In this case and in 
>others, you might have different geometries for different styling.

well, i think that any two svg images with different geometry have different 
content so they _should_ be in separate documents, since geometry is part of 
the SVG content being described.  they could share the same stylesheet 
dictating fills, fonts, strokes, etc. though.

>Clipping paths are a particularly interesting item. It is easy to think of 
>clipping paths simultaneously as geometry and styling.

yes. that's why it was difficult for me to decide if clipping an masking 
should be strictly banished to CSS.

>>>I would imagine the strongest argument for placing a functionality in CSS 
>>>as opposed to SVG would be if it is a functionality that would be used by 
>>>other namespaces that use CSS (i.e. XHTML)...
>>
>>[...]<shrug/>
>
>When deciding whether a trait should expressed using styling properties, 
>the SVG working group did ask itself whether this trait might be useful to 
>other XML presentation languages, such as XHTML. For example, the ability 
>to fill and stroke text is something that XHTML might want to support in 
>the future. Therefore, 'fill' and 'stroke' are styling properties.
>
>>>Interesting thought though, do you have a rigorous definition of what 
>>>would move to CSS?  Seems to me it would be hard to draw the line.
>
>Definitely hard to draw the line.
>
>>[...]gradients and patterns should be the first to go to CSS.  other 
>>features that i think <em>might</em> be better placed in CSS are filter 
>>effects and possibly masking/clipping (though i'm not too sure about that 
>>one).[...]
>
>Note that SVG has styling properties for masking ('mask'), clipping
>('clip-path', 'clip', 'overflow'), gradients and patterns ('fill' and 
>'stroke'), and filter effects ('filter'). There are also corresponding 
>elements: <mask>, <clipPath>, <linearGradient>, <radialGradient>, 
><pattern>, and <filter>[...]

but i still can't shake the feeling that these tags need to be separated 
from the SVG namespace.  i realize that eliminating the tags altogether 
would put an awful burden upon CSS, but perhaps they might be better placed 
elsewhere.  perhaps there needs to be a FontML and a FilterML and a 
CompositeML (<- maybe).  patterns, i believe, should easily be integrated 
into CSS; they're like backgrounds for the foreground (where's Tim Boland).  
gradients i think should be handled by the group dealing with the 
color/gamma/color profiles CSS module (Mr. Lilley?).
>
>Jon Ferraiolo
>SVG Editor
>jferraio@adobe.com
>
>>>I wonder what Chris Lilley will have to say about the criteria for 
>>>placing functionality in SVG as opposed to CSS.
>>
>>as would i.

>>>Max
>>>www.siliconpublishing.org/
>>
>>                                                &#8226; mjumbe &#8226;

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Received on Wednesday, 9 May 2001 10:50:57 UTC