- From: Mjumbe Ukweli <mjumbewu@hotmail.com>
- Date: Wed, 09 May 2001 10:50:14 -0400
- To: jferraio@Adobe.COM
- Cc: www-svg@w3.org, maxdunn@siliconpublishing.com
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/ >> >> • mjumbe • _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Received on Wednesday, 9 May 2001 10:50:57 UTC