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

Re: Reconsider SVG 1.2

From: Kurt Cagle <kurt@kurtcagle.net>
Date: Wed, 17 Nov 2004 01:46:55 -0800
Message-ID: <419B1E0F.7040908@kurtcagle.net>
To: Boris Zbarsky <bzbarsky@MIT.EDU>, www-svg@w3.org

 > Yes, one could.  In fact, that's exactly what's been happening over 
the last year or two.  CSS 3.0 work more or less halted and the working 
group worked on CSS 2.1.  Which is 2.0 with the parts that have not been 
implemented removed, the parts that were unclear clarified based on 
implementation experience, and so forth.  The plan is to not take CSS 
2.1 out of CR until there is a good test suite for it, one passed by 
implementations.  Something that both CSS 2.0 and SVG (all versions) 
sorely lack.

Once SVG 1.2 goes out of Last Call it goes into a call for 
implementation phase; I'm assuming for the nonce that Adobe will have 
its implementation, and I am aware of a couple of open source SVG 1.2 
implementations that are well into the development stage (I'm working 
with Ronan Oger of Vectoreal on one of them). I don't think anyone plans 
on seeing SVG out the door without these.  The test suite issue is a 
good one, but given the fairly limited scope of the changes in SVG 1.2 I 
don't necessarily see the construction of such a suite being a 
particular hardship -- I may very well write one myself and submit it to 
the W3C gratis. SVG 1.2 does not, for the most part, significantly 
change the behavior of either 1.0 or 1.1; thus is it not necessary to 
replicate the ENTIRE SVG test suite except in areas where overlap does 
exist (such as the compositing model).

One thing you may want to look into, if the issue is that important to 
you on the CSS side, is the establishment of a technical committee 
within OASIS to perform SVG validations, as already exists for XSLT 1.0 
implementations (XSLT 2.0 suites are underway).

>> SVG 1.2  is a complementary specification to SVG 1.1 - it provides 
>> functionality in areas for which people have been requesting that 
>> functionality, including multimedia, text-flow, sockets, component 
>> generation and editing.
> All of which has naught to do with vector graphics and duplicates 
> existing functionality existing in application contexts (keep in mind 
> my perspective here as a web browser developer).

My experience with vector graphics began about eighteen years ago when I 
started working with Postscript in conjunction with Mathematica. Much of 
what was done with VG at that time was animation related, albeit at a 
very early level, because of the realization that vector graphics 
significantly extends the scope of what we mean by graphics in general. 
I personally thing that SVG is misnamed, because the focus even early on 
was not so much on providing a way of handling vectorized graphics, but 
on the ability to create distributed graphics -- something that has a 
huge impact for areas such as GIS, with the implicit handling of 
multiple levels of abstraction. It is the distributed nature of SVG that 
necessitates the use of sockets, just as the DOM 3 specifications 
recognized this through its own distributed routines. Multimedia is a 
somewhat more problematic call, though I think it is legitimate. 
Bindings are not SVG, but as someone who uses them extensively within 
XUL, they ARE a useful step for turning SVG into a component framework, 
something I see a definite need for.

One of the most controversial aspects that I see here is in the use of 
flowing text - certainly this is the most contentious, because there is 
a camp that believes that this should be the domain of HTML (and by 
extension, CSS). I don't agree with that. I've been developing SVG 
applications for five years (I worked for a while with both VML and PGML 
before the spec was solidified) and have found that flowing text is one 
of the biggest problem areas in SVG 1.1, usually forcing me to write my 
own routines that are running in the very slow Javascript space. The 
solution that has been proposed is very elegant, solves a lot of 
problems, and works well within the framework of SVG.

> I'm aware of this.   Why not just make the standard say "do whatever 
> the Adobe viewer does" and be done?  Clearly, "Adobe implements it" 
> should not be the deciding reason for adding things to the spec.

I do not work for Adobe, and frankly there are times that I find that 
Adobe does, yes, have an undue influence on the specification. This is 
not atypical of the W3C specifications - Microsoft is all over both WSDL 
and SOAP, for instance - but at the same time they have been throwing 
significant programming cycles trying out a lot of things in that space 
that others have chosen (or don't have the resources) to do. The SVG 
specification however has a LOT of cosignatories, and from personal 
experience this translates into often contentious arguments that have 
kept Adobe from getting a significant upper hand.

I've actually made a number of suggestions over the development lifespan 
of the SVG specification that I know from direct contact with the W3C 
committee has become part of the specification.  The trick is simply 
knowing when to make the suggestions.

> Note that I found out just yesterday that the Adobe viewer's 
> implementation of the CSS cascade and of SVG stylistic attributes and 
> their place in said cascade is completely broken.  There's a very 
> clear paragraph in SVG 1.1 that says what the right behavior is and 
> the Adobe viewer does nothing remotely resembling that.  Given that 
> it's the most commonly used viewer in many markets, I fully expect 
> there to be content out there that depends on this bug.

The CSS implementation within Adobe's viewer actually works reasonably 
well -- I've written a book on it "SVG Programming" for Apress, and used 
CSS pretty heavily in it. ASV 3.0 is not perfect in this regard, but to 
describe it as "completely broken" is something of an overstatement. By 
that same light you can argue that CSS is totally broken in Internet 
Explorer (and in that case be probably closer to the truth).

> Right.  But
> 1) They don't need to exist as part of SVG
> 2) If what SVG defines is significantly different from what already 
> exists,
>    there is no way to leverage the existing capabilities.
> #2 is the heart of the arguments about whether the text-flow in SVG is 
> compatible with the text-flow in CSS.  From what I can tell, the 
> algorithms involved would be sufficiently different, at a very basic 
> level, that they could not leverage each other.  Both are very 
> complicated algorithms, and having to implement two such instead of 
> only one will simply lead to more bugs.  All this quite apart from the 
> additional memory overhead of having all that extra code, of course...

Here I would respectfully disagree. I would prefer not to invoke four or 
five different namespaces in order to put a paragraph of text in a 
graphic. HTML + CSS is not, IMHO, sufficiently powerful to do what I 
could do with most text layout programs a decade ago - the model simply 
isn't there. The domain of HTML is in the deployment of web pages, and 
it is eminantly suited for that. SVG's domain is both broader and more 
low level - one COULD implement an HTML browser in SVG reasonably 
enough, though it requires a lot of dependencies upon scripting to do so 
with SVG 1.1 - but this is only one domain of many where SVG is being 
utilized.  The CSS flow model has no real notion of non-rectangular 
flow, and saying that a future CSS implementation MIGHT eventually have 
one strikes me as being specious.

As Ronan so elegantly put it, SVG could very well exist without CSS, and 
I suspect that with sXBL it would actually be better off without it. You 
wouldn't need to have two implementations in that case. The CSS support 
as it exists right now has come about more on the insistence of the CSS 
community for its inclusion rather than because SVG requires it, and SVG 
Tiny explicitly does NOT include it because of the memory overhead.

> The problem is finding people to do the programming.  There's a 
> chronic shortage.

Make something compelling enough, and you can get the people to program 
it. The Mozilla team is ramping up its SVG support - SVG is becoming 
part of the substrate for the next generation X Servers on Linux boxes 
(see my blog at 
for more info), and with IBM, Novell and Sun seeing SVG as part of a 
general solution to take on XAML and the Microsoft world-view the money 
(and hence the programmers) is finally beginning to arrive, after the 
period of the Long Nuclear Winter. 

> I have nothing against SVG 1.2 going out the door.  I am adamantly 
> against it going out the door like 1.0 and 1.1, without a test suite, 
> with implementations that are wildly incompatible with each other and 
> the spec itself, with the spec unclear enough that I, as an 
> implementor, can't tell what my implementation should be doing.

Are you actually implementing the SVG 1.2 specification? I'd love to see 
it if you are. I've reviewed the specification pretty careful (as an 
author working on my third SVG book, so I've had a little experience 
dealing with both good and bad Recs). The specification as it exists is 
actually pretty good -- there are still a few rough spots yet (I'd like 
to get clarification on XPath within XBL, for instance) but for the most 
part the specification is staying pretty close to the notion of 
canonicalness. Every element has an RNG definition, the ambiguities have 
been pretty well ironed out. I figure once we get through the 
implementation phase, anything that could be unclear should become 
obviously so, which is why that phase exists, but I personally cannot 
see these ambiguities that a few people are complaining so vocally about.

Most of the principle objections that I've seen from people on SVG 1.2 
have to do with its "potential" collision with a currently unpublished 
working draft of CSS dealing with text flow. I HAVE seen that 
specification, and while I think that it could do a certain amount in 
helping HTML become more newspaper-like, there's also still a lot of 
handwaving concerning such things as non-rectangular text flow and 
disconnected flow regions. The SVG implementation provides one solution 
to that, one that frankly is actually quite elegant for handling some of 
the more problematic issues involved in recreating such solutions in 
XML. I suspect the reason that there is this animosity has more to do 
with the fact that it will potentially obviate the work done by the CSS 
working group than any arguments on technical grounds.

There's one major consideration that I'm not seeing from the CSS side - 
SVG is XML. I do not have to bind SVG with PIs, I can generate SVG from 
XSLT transformations, I can manipulate SVG using the XML DOM. That's 
always been the promise of SVG, and always been the downfall of CSS. I 
spent a summer with the XAML team at Microsoft for a book, and they 
dismissed CSS out of hand for precisely those reasons (while creating 
their own fairly graphical spec that almost exactly mirrored SVG, except 
without the CSS). Even if CSS does add support for all the deficiencies 
mentioned before, I will still prefer to use SVG because it is XML.

> The point of a spec isn't to be able to point to a feature and say, 
> "Look, we're following the spec" (though that is a big plus for Adobe, 
> of course).  The point is to have multiple implementations all 
> implement the same functionality in the same way so content authors 
> can depend on it.

SVG, much like most of the W3C specifications, is not a specification in 
the same way that something even like HTML was. HTML existed prior to 
the existence of the W3C - and the organization in turn had to spend a 
great deal of time and energy trying to catch up and tame HTML as it 
shifted from form to form. Specs like SVG or XSLT2 are more along the 
lines of goals - targets to be reached - than they are ratifications of 
existing technologies.  It's a big part of the reason that these 
specifications are called Recommendations. By having the recs out there, 
it becomes possible to use it as a benchmark for compatible systems, and 
most such systems can readily document where they fall short of the 
benchmarks. Given the comparative newness of the technology (and the 
deliberate non-adoption by the largest Internet browser manufacturer, 
Microsoft) it WILL take a year or so before you see the first SVG 1.2 
non-proof-of-concept implementations really take hold, but within four 
years, SVG 1.2 will be pervasive.

None of the CSS 3.0 modules are Recommendations.  Very few are even in 
CR (two that I can think of), and things that are not in CR are 
explicitly _discouraged_ from being implemented except with vendor 
prefixes, as they are subject to change at any point.

> The current Last Call and CR rules exist to ensure that a 
> specification does not become a Recommendation until there _are_ 
> compliant implementations.  It's pretty clear to me that the SVG 
> working group is planning to pay lip service to these rules at best.

As I have yet to see any implementations, this claim rings hollow. SVG 
1.2 will not proceed into CR status until it has been well tested, but 
even major SVG vendors such as Adobe are waiting for the WD to freeze 
long enough to get some reference implementations out to the public.

-- Kurt Cagle
Received on Wednesday, 17 November 2004 17:31:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:01 UTC