- From: Dean Jackson <dean@w3.org>
- Date: Wed, 24 Nov 2004 02:12:16 +1100
- To: Ian Hickson <ian@hixie.ch>
- Cc: www-svg@w3.org, Peter Sorotokin <psorotok@adobe.com>
On 24 Nov 2004, at 00:09, Ian Hickson wrote: >>>> - there is a need to assign multiple strokes and fills to an object >>>> (drawing tools had this for long time) >>> >>> This could be done in the same way that the CSS working group is >>> handling multiple backgrounds on elements, namely, let the 'fill' and >>> 'stroke' properties take multiple comma-separated values. >> >> That was certainly one of the ideas WG members had as well. It works >> for >> fill, but stroke is not controlled purely by stroke property. >> Typically >> one wants to change either stroke-width or stroke-dash-array as well. > > Allowing those properties to take multiple values as well would address > this (and is how 'background' is being handled in CSS). This has a number of problems. - It makes it much harder to use tools like XSLT. - It adds another micro-syntax to the language that implementers have to handle. - It makes it extremely difficult, if not impossible, to animate different sub-properties or individual entries in the properties independently (without adding a whole set of language features just to do this). > While I now understand why you feel these new features are important, I > still think the current proposed way of doing them is hugely over- > engineered and overly complex. It allows shapes to have other paths > arbitrarily applied to them, for instance. Actually the stylistic effects are fairly easy to implement, and IMO are an obvious extension to the existing rendering model. It is also a nice match to the raster effects. > > I mean, come on. If you want a shared edge on a map, just use one path > element, with one stroke, instead of having the edge drawn by both > elements. And how do you know which of the two sides you are in when you put your mouse over the object? > > >>>> - all of the above should integrate with animation (e.g, path >>>> animation) and not cause substantial file size bloat. >>> >>> The two proposals I list above (a new unit and allowing multiple >>> values on two propeties) seem to handle this. Your proposals don't handle animation very well. Dean
Received on Tuesday, 23 November 2004 15:12:20 UTC