RE: separating svg data from presentation

>>>>> "MU" == Mjumbe Ukweli <mjumbewu@hotmail.com> writes:

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

MU> absolutely nowhere.  i would automatically assume that any XML
MU> namespace is used to describe data because that's what XML does;
    [...]

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

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

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

MU> it would certainly be difficult, but perhaps worth the effort so
MU> here i go.  i would say that gradients and patterns (aka
MU> background images) should be the first to go to CSS.  

    What about the fact that patterns are defined with SVG primitives?
The issue being that it's all well and good to say that what ever a
geometric object is filled with is a style issue, but you still need
to define that filling, the definition of the filling is done with SVG.

    In fact fill and stroke _are_ CSS properties (they also have
attribute representations) it's just that they often reference SVG
content for there value.  If someone else wanted to reference an SVG
gradient to fill the background of there HTML page they can do that
(assuming of course the viewer will render such references :).  So I'm
not sure what you mean by they should be moved to CSS.

    The other really killer issue is of course the fact that often it
is very desirable to consider styling when computing the placement of
objects (or in other words the geometry).  We just take this for
granted with normal text. For example if you embolden text it often
gets wider, usually not a problem for a normal HTML text flow, but in
SVG if a box has been put around that text you may now overflow.

    In general the approach in SVG has been to enable creators to
write stylable SVG but not require it.

MU> other features that i think <em>might</em> be better placed in CSS
MU> are filter effects and possibly masking/clipping (though i'm not
MU> too sure about that one).  none of these (except arguably
MU> masking/clipping) falls under the categories of the "three types
MU> of graphic objects: vector graphic shapes..., images [or] text."

    Once again all of the things you have described as 'style'
elements (including 'filter', 'clip' and 'mask') are defined as CSS
properties (as well has having attribute versions) it is just that
normally these properties reference elements of an SVG file since no
other grammar provides good tools for describing what the desired
"styling" effect should be.  Incidentally, filters really go way
beyond simple styling, since they can be used to do very complex
compositing operations, to generate output (they can also be used to
just apply simple drop shadow effects, which could be considered a
style issue, but in general they go way beyond this).

    I hope this helps to clarify some of the interactions and how SVG
and CSS 'play together'.

Received on Tuesday, 8 May 2001 15:58:18 UTC