- From: Kurt Cagle <kurt@kurtcagle.net>
- Date: Wed, 17 Nov 2004 01:46:55 -0800
- 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 http://metaphoricalweb.blogspot.com/2004/11/theyre-movin-and-shakin-at-w3c.html 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