Re: SVG 1.2 Comment: vector effects

On Sat, 6 Nov 2004, Andreas Neumann wrote:
> 
> As a content creator and cartographer I can only second Peters and Dougs 
> comments. Many of the more complex map symbolization problems can be 
> adressed using vector effects. [...]
> 
> Besides that, vector effects can help to solve quite a few GIS analysis
> features (such as intersection, excluding, merging of elements). Doing it all
> by script would be complex and slow, besides the problems that Doug mentioned,
> regarding semantics.

I don't really see that it is appropriate for the Web browser to have 
built-in support for GIS analysis. I don't doubt that it would be very 
useful in your domain, but there is a line to be drawn at how much a Web 
browser needs to support.

To give parallels with HTML -- HTML has support for a definition list - 
<dl>/<dt>/<dd> -- which can let you write, for instance, a glossary. 
That's great, but dictionary and encyclopedia authors ask why doesn't HTML 
also have support for saying that a word is a noun? Or an adjective? Why 
is there no way to define the syllables of a word? Why is <dd> only one 
level deep, allowing for multiple definitions but not sub-definitions? Why 
is there no markup for highlighting the root of the word, the 
pronounciation of a word, the etymology of a word?

The answer is that HTML -- like SVG! -- should be a generic language, 
suitable for a wide range of fields, relatively simple to implement. For 
more specific work, like writing a dictionary, more specific languages 
should be used, which can then be transformed into HTML when it comes to 
the final stage of showing it to the user.

The same should apply to SVG. Sure, on the server side you probably want 
to embed custom namespaces to label roads, altitudes, gradients, and other 
geographical and geological features. But when the map is finally shown to 
a Web UA, it would be inappropriate to expect the user agent to be able to 
intelligently handle all that data.

So yes; simple things like keeping the strokes the same width despite 
zooming seem like they could be cheaply supported in SVG. More complicated 
things such as client-side fill intersections, unions, etc, seem excessive 
for a Web UA.


> Of course, not every SVG viewer needs to implement vector effects. That's why
> we have profiles. I totally understand, that a SVG basic or SVG tiny renderer
> cannot adress vector effects.

I am concerned about the "Web UA", that is, the UA that normal Web authors 
will target. If a feature isn't included in the "Web UA", then it might as 
well not be in the spec -- as several people have said, the SVG Full specs 
represent what the working group think should be implemented by Web UAs.

Note that since I do not want to see a fragmentation of Web standards, 
where browsers support one language on small devices and another 
incompatible language on desktops, I only consider there to be one "Web 
UA" version of SVG. Whatever desktop UAs implement is what mobile UAs 
should implement. (The same is true for CSS, HTML, DOM, etc -- Mozilla and 
Opera, the two UAs that are available on desktop and mobile spaces, both 
implement the same specs in both spaces.)

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

Received on Wednesday, 10 November 2004 12:07:55 UTC