RE: separating svg data from presentation

My opinions on the subject are interspersed below.

At 03:11 PM 5/8/01 -0400, Mjumbe Ukweli wrote:
>>From: "Max Dunn" <maxdunn@siliconpublishing.com>
>>Date: Tue, 8 May 2001 10:07:07 -0700
>>
>>Hi Mjumbe,
>>
>>That's an interesting perspective.  Where did you hear it stated that SVG
>>was "concerned with describing the geometry of an image, not the color,
>>etc."?...
>
>absolutely nowhere.  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.  the W3C says that "SVG is a 
>language for describing two-dimensional graphics in XML."  clear 
>enough.  "SVG allows for three types of graphic objects: vector graphic 
>shapes (e.g., paths consisting of straight lines and curves), images and 
>text."  okay, stop.
>now right there we have our data: vector shapes, images and text.  what 
>can we do with it?  "Graphical objects can be grouped, styled, transformed 
>and composited into previously rendered objects."  alright, we're 
>set.  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.

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

Nevertheless, the above distinction sounds pretty good to me, except for 
compositing. Compositing naturally belongs wherever opacity, clipping and 
masking go. In your suggestions below, you have clipping and masking 
classified as "styling".


>>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)...
>
>that was the idea that i was going for, actually.  there are times when 
>i'd like to use a gradient background for my html documents without 
>reverting to an background-image.  there maybe someone who wants to put a 
>bevel on his or her mathml content.  <shrug/>

In section 6.1, the SVG specification provides some of the rationale for 
what things were defined to be styling properties.

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.


>it would certainly be difficult, but perhaps worth the effort so here i go.
>i would say that gradients and patterns (aka background images) 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).  none of these (except arguably 
>masking/clipping) falls under the categories of the "three types of 
>graphic objects: vector graphic shapes..., images [or] text."

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>. The elements get referenced by the corresponding 
properties. Elements were used to define the complex styling effect in 
order to leverage the advantages of XML and to keep from defining zillions 
of additional styling properties.

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 Tuesday, 8 May 2001 17:49:06 UTC