Re: SVG 1.2 Comment: vector effects

On Mon, 29 Nov 2004, Bjoern Hoehrmann wrote:
> > 
> > I appreciate that there is a demand for these features, don't get me 
> > wrong. My concern is that this demand isn't coming from Web authors. 
> > Indeed, the demand from authors targetting the "quotidian Web" (for 
> > lack of a better term) would be for open vector graphics of _any_ 
> > kind, since all that such authors have right now is Flash. Authors who 
> > have enough experience with SVG to be able to make feature requests 
> > almost be definition aren't authors targetting the Web that Web 
> > browsers are primarily concerned with.
>
> What is exactly the definition of "vector graphics" you are using here?

The representation of separate shapes such as lines, polygons and text, 
and groups of such objects, as opposed to bitmaps. [1]


> I am not quite sure where you draw the line between graphical elements
> authors create using CSS features such as the "border" property, vector
> graphics that are pre-rasterized to some bitmap graphics file format
> before they get published as part of a XHTML+CSS layout like for example
> cliparts, type in a specific font or animated ads, interactive maps
> where the map data is pre-rasterized to some bitmap graphics file format
> and accessed via Java applets from browsers, interactive graphical
> online games, interactive virtual reality environments, and so on.

'border' is vector graphics to some extent, but (ignoring the quite insane 
things Tantek has managed to do with them) don't let you do arbitrary 
shapes.

Anything pre-rasterised to a bitmap format isn't a vector graphic at the 
client side.

Fonts are (these days) based on vector graphics, but with the exception of 
certain pictures available in Unicode, don't let you do arbitrary shapes.

Animated ads could well use vector graphics. Indeed, along with cartoons 
and games, animated ads in the proprietary Flash format are a large part 
of the vector graphics content currently on the Web.

Hopefully that answers your question.


> Your definition of "web author" is also not clear to me, maybe you could 
> describe the characteristics of the people you mean more clearly? Are 
> these people HTML+CSS+JavaScript authors that attempt to turn Photoshop 
> graphics into a "web site" or is it more the set of people involved with 
> doing flash sites like http://www.unfortunateeventsmovie.com/ or are it 
> professional design companies that do stuff like corporate identities or 
> professional graphical user interface designers involved with doing the 
> user interface for desktop applications or computer games, or the people 
> who did the interactive SVG maps that visualize the results of the last 
> european election in germany, or whom did you have in mind?

All of the above. My point is that while some minorities in this (very) 
large community may have very specific needs from a vector graphics 
format, most do not, and for most, therefore, the features in SVG 1.2 are 
overkill. In the same way that HTML doesn't solve every technical writer 
requirement, SVG shouldn't attempt to solve every graphical requirement.


> Finally, it is not really clear to me where Shockwave Flash fits into 
> this picture. Have you or Mozilla or Opera complained about increasing 
> complexity in Shockwave Flash recently?

Ironically, yes, the increased footprint of Shockwave Flash has been of 
concern. However, Flash is a self-contained format that doesn't need to 
interact with the existing browser code, and is a proprietary format 
implemented by one vendor and therefore interoperability is largely 
irrelevant. SVG, on the other hand, is supposed to integrate with the 
existing browser engine, and is supposed to be interoperably implemented 
by multiple vendors. The problems of increased complexity are therefore 
orders of magnitude more important for SVG than for Flash.


> As you apparently do care about the complexity of SVG 1.2 it would seem 
> that you do not consider it an option that SVG implementation will be 
> offered through the same mechanisms that make Shockwave Flash work today 
> which either means that you do not expect that anyone will implement SVG 
> 1.2 to the extend required, or that there are specific reasons why these 
> mechanisms will not work well (probably in the longer term) for SVG 
> implementations and that the implementation work needs to be done by 
> these browser vendors. If that is not your point I am not sure how it is 
> actually relevant whether web browser vendors will implement SVG 1.2.

We are getting requests to implement SVG natively, and being told that 
third party SVG renderers are not an acceptable long-term solution. If we 
are to act on these requests, we need to be convinced that SVG isn't going 
to be as complex as it currently is.

[1] http://dictionary.reference.com/search?q=vector+graphics&r=67
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 7 December 2004 21:13:38 UTC