Re: SVG 1.2 Comment: vector effects

On Wed, 24 Nov 2004, Craig Northway wrote:
> > > 
> > > This has a number of problems.
> > > 
> > > - It makes it much harder to use tools like XSLT.
> > 
> > That's an XSLT limitation, and should not restrict the SVG group from 
> > making a good quality language.
>
> I think that making a good language would include making one that can be 
> operated on easily by existing tools. I think that complex attribute 
> syntaxes should be avoided because they significantly increase 
> implementation complexity.

I honestly don't see that a complex element structure is better than a 
complex attribute syntax.


> > > - It adds another micro-syntax to the language that implementers 
> > >   have to handle.
> > 
> > So does adding a bunch of new elements.
>
> As Thomas said it much easier to add elements to an XML based language than
> complicated attribute syntaxes.

Our experiences apparently differ.

> > How about a new kind of paint server that defines the paint servers 
> > that should be used?
> > 
> > As in,
> > 
> >   <paintServer id="foo">
> >    <solidColor solid-color="blue" solid-opacity="0.8"/>
> >    <solidColor solid-color="red" solid-opacity="0.8"/>
> >   </paintServer>
> > 
> >   <circle fill="url(#foo)"/>
> > 
> > Here you only need one element to introduce the idea of multiple fills, and
> > it fits into the current model well.
> > 
> > For multiple strokes, the simplest solution would be to just have multiple
> > <path> elements all using the same path definition, each with a different
> > stroke. Alternatively you can introduce a new "strokeServer" which would
> > take one or more elements <stroke> which have all the stroke-* properties:
> > 
> >   <strokeServer id="bar">
> >    <stroke stroke="red" stroke-width="4"/>
> >    <stroke stroke="white" stroke-width="2"/>
> >   </strokeServer>
> > 
> >   <circle stroke="url(#foo)"/>
> > 
> > Again, this introduces minimal new elemenst while allowing the requested
> > features.
>
> This does not solve many of the solutions vector effects does, in 
> particular where strokes, fills and markers can be combined in different 
> orders.

Indeed it doesn't. The whole point of my feedback is that SVG 1.2 should 
be dramatically simplified so that it addresses the use cases that will be 
heavily used, resulting in a simple easy to use and easy to implement 
specification, at the expense of the more exotic use cases.

> > The requirements Peter listed as reasoning for the vectorEffects 
> > feature were: [...]
>
> These may not be the only requirements, Peter adding the caveat "In 
> short" to the start of this list.

I think the requirements that make the "in short" list are the only 
requirements that a W3C spec intended for use by the HTML Web authoring 
community, and for implementation in Web browsers, should support.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 29 November 2004 05:08:07 UTC