- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 10 Nov 2004 12:07:41 +0000 (UTC)
- To: Andreas Neumann <neumann@karto.baug.ethz.ch>
- Cc: www-svg@w3.org
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