W3C home > Mailing lists > Public > www-svg@w3.org > November 2004

Re: SVG 1.2 Comment: vector effects

From: Ian Hickson <ian@hixie.ch>
Date: Mon, 29 Nov 2004 10:14:43 +0000 (UTC)
To: Andreas Neumann <neumann@karto.baug.ethz.ch>
Cc: www-svg@w3.org
Message-ID: <Pine.LNX.4.61.0411290947010.24069@dhalsim.dreamhost.com>

On Mon, 29 Nov 2004, Andreas Neumann wrote:
> 
> the browser vendors did not care about SVG 1.0 when it was released, 
> when it was simpler than SVG 1.2. Suddenly, they complain that it might 
> get too complex. 4 years after SVG 1.0 was released.

To be honest, four years ago SVG wasn't even on our radars. Netscape and 
Mozilla were in the midst of a massive rewrite of their HTML rendering 
engine (Netscape 6.0 shipped some six months after SVG 1.0 hit Last Call), 
Opera were busy with Opera 4.0, Microsoft were busy adding their own 
proprietary features and shoring up their CSS support; the Web Standards 
Project was trying to get browsers to support CSS1 reliably... Personally 
I was at University involved with two of those projects, and I can tell 
you that vector graphics were the furthest thought from my mind as far as 
the Web went.

(Despite the above, I did send some last call comments. I'm sad to note 
that the CSS working group sent similar comments for SVG 1.2, since 
apparently several of the issues have still not been addressed.)


> I would be perfectly happy if the browser vendors would provide a full, 
> clean implementation of SVG 1.0/1.1 and for now leave SVG 1.2 to more 
> specialized SVG UAs, such as ASV/Batik or others.

The problem is that whatever we implement, our customers will demand that 
we do everything that the W3C has stamped.


> As to the complexity of vector effects: yes, they might not be trivial to
> implement, but they are certainly doable.

Everything is doable. See my .sig. That isn't really the point. We have to 
implement a bazillion specs and we have to do so in a tiny amount of space 
with a finite number of engineering and testing resources. It simply isn't 
feasible nor desirable to support redundant or rarely-used features.


> And there are tons of graphics applications out there that do implement 
> them. Or do you know any serious vector graphics application out there 
> that does not implement union/intersect/path offset, etc?

But my point is a Web browser isn't, and shouldn't be, a "serious vector 
graphics application".


> As to your other argument, that vector effect would only be needed by 
> less then 10%:
> 
> I don't buy this argument. There are many features in HTML/CSS that less 
> than 10% of the people use, and still they are here and used.

Actually most of these rarely used features were never implemented and 
have now been dropped in CSS2.1. And many features that we were planning 
on adding to CSS3 are being dropped because they would also increase 
complexity without much gain for the majority of authors. Speaking just 
for the specs I'm an editor of, for instance, the CSS3 Generated Content 
module in the last published draft suggests multi-level nesting of 
pseudo-elements. Based on implementor feedback, we've decided to drop all 
of that and restrict pseudo-elements to a very few defined combinations.


> If you want, you could also do a poll on the svg developers list and 
> would find out that a lot of people on this list would have a use case 
> for one or more features of the vector effects proposal.

That's a self-selected group, and is not representative of the people that 
Web browsers would be targetting in so far as vector graphics are 
concerned. It _is_ an important group, of course, but for most users, 
their primary contact with vector graphics is sites like:

   http://badgerbadgerbadger.com/

...and I don't see anything in the graphics of that animation that 
requires more than <path> and animation features.

Currently the difference between SVG1.2 and the vector graphics language 
that Web UA manufacturers would like to implement is roughly the same as 
the difference between Docbook and HTML, IMHO. DocBook serves a very 
important role in specialist environments (and there are a lot of those 
environments), but at the end of the day, HTML is good enough for the 
Web's document needs. (It leaves something to be desired when it comes to 
apaplications, but that wasn't what it was designed for.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 29 November 2004 10:14:46 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:53 UTC