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

Re: SVG 1.2 Comment: vector effects

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 7 Dec 2004 20:30:25 +0000 (UTC)
To: AndrewWatt2001@aol.com
Cc: www-svg@w3.org
Message-ID: <Pine.LNX.4.61.0412072011560.18787@dhalsim.dreamhost.com>

On Mon, 29 Nov 2004 AndrewWatt2001@aol.com 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.
> 
> What lesson do you draw from that about the far sightedness (or 
> otherwise) of your radar?

That it was too short; that's why now we _are_ reviewing specs that we 
won't be implementing for years, if ever.


> > > 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.
> 
> Is this a fundamental reason for your assorted objections to SVG 1.2? 

For many of them, yes.

> That you (corporately) don't have the vision or resources to implement 
> what the market wants?

If we thought "the market" wanted SVG 1.2's many features, we probably 
wouldn't be having this discussion. The whole point is that there are many 
parts to the market, and we are not hearing the demand you are apparently 
hearing when it comes to the more complex parts of SVG 1.1 and 1.2.


> > > 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.
> 
> Isn't there a circularity of argument here? You don't support it, so 
> it's rarely used, so because it's (in your perception) rarely used, you 
> shouldn't support it?

By "rarely used" I meant "that would be rarely used even if implemented". 


> > > 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".
> 
> Why? Isn't that statement also indicative of a narrowness of view?

Because it should be an application platform and an interactive document 
viewer, and that doesn't imply it has to be a serious vector graphics 
application.

We (browser makers) get requests from every corner of the market saying 
that their feature is critically important, that the entire market would 
jump on the feature if it was available, that browsers should be a 
"serious [whatever] application" and that it is narrowminded of us not to 
jump on their bandwagon and implement their specs. SVG is by _far_ not the 
only community asking to be implemented.

Thus, the specs that _do_ end up being implemented have to be relatively 
simple and easy to test. If they aren't, then the features will either not 
be implemented, or will be unacceptable buggy. Just think about how long 
it has taken browsers to get HTML4+CSS1 done in an acceptable way. (And 
some would say nobody has actually succeeded yet!) Now compare the sizes 
of the HTML4+CSS1 specs with the SVG1.1 and SVG1.2 specs.


> Should the Web browser (or Web client, if you want a less narrow term) 
> be permanently fossilised because of that?

There are many more options than "implement everything proposed in SVG 
1.2" and "do nothing at all". There are multiple browsers that are in 
active development, implementing new features with every release. Just 
because we don't think that Web browsers should support (say) solidColor 
in SVG doesn't mean that we think browsers should stop supporting new 
features.


> > It _is_ an important group, of course, but for most users, their 
> > primary contact with vector graphics is sites like:
> > 
> >   http://badgerbadgerbadger.com/
> 
> Fifteen years ago, for most users, there was no perceived need for a Web 
> browser. Where would your line of thought have taken us (or failed to 
> take us) over the last 15 years?

Pretty much exactly where we are now. HTML was the result of rejecting the 
overly complex hypertext and document market technologies that came before 
it (SGML, e.g.), and instead developing a simple solution that did just 
the 80% or 90% that was needed. The same with CSS1 -- it was a simple spec 
which didn't attempt to do everything in typography, rejecting the overly 
complex alternatives that came before it (DSSSL, e.g.) and mostly ignoring 
the clamours of "market need". CSS2 was a step backwards, trying to do too 
much for too many people, and the CSS group had to strip features out and 
simplify the model (CSS2.1) to make browser makers consider implementing 
the entire spec (a process which is now underway).

SVG1.2, as far as I can tell, is the exact opposite: it's an attempt to 
provide everything everyone needs. The question is what market does SVG 
want to address, the high-end market, or the Web?

SGML is very successful. But it isn't successful on the Web. It took XML 
(a massive simplification of SGML) to get it implemented in Web browsers.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 7 December 2004 20:30:28 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:29 GMT