- From: Thomas E Deweese <thomas.deweese@kodak.com>
- Date: Tue, 8 May 2001 15:58:02 -0400
- To: mjumbe@electricstoat.com
- Cc: maxdunn@siliconpublishing.com, www-svg@w3.org
>>>>> "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