- 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
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 UTC