Opera 9.0 Beta is now available for download. For those of you who have regularly tested the 9.0 previews and weeklies the difference from those isn’t that great (except in stability), but from 8.5 it is huge. There are new features and advances in standards. One that has truly progressed since 8.5 is SVG. While we don’t have complete SVG Basic support yet, with full styling and scripting, we are close. Getting here has been a long journey.
The first version of SVG, SVG 1.0, became a W3C Recommendation in September 2001. We had an interest in SVG even earlier, but the sheer size of the specification made us decide against it, it was hard to justify putting so much effort into a format that was going to need years to get a foothold in the market. We had done it with PNG before, but that was easy. The arrival of the Adobe plug-in decided the matter, why should we spend our remaining resources on SVG when there was a viable alternative?
We weren’t looking for a Flash competitor, which seemed to be Adobe’s main drive until they bought Flash several years later. It definitely wasn’t to make a Purity of Essence markup language not sullied by the real world like the HTML harlot – many working group members at that time were deeply hostile to the Web. The mobile companies were the next to turn on to SVG, and while there are clear benefits with SVG on phones, the gains can be even larger on a larger screen.
We saw a vector graphics markup language as an adjunct to HTML, together they would become more than they were separately. Each language could provide what the other one could not. HTML augmented with CSS could do both text, layout, hypertext, semantics and more. But it couldn’t do the simplest illustrations (except through brutal hacks), or graphs, or fancy boxes or headlines. As HTML was a W3C language and SVG was a W3C language you would have expected that these two were well integrated, that you could easily use one to enhance the other.
That certainly isn’t the case and this is a tremendous unfulfilled promise. It isn’t all bad, the two languages do integrate with each other after a fashion. They can be looked at as feuding siblings, having them in the same room will cause torment, but they are family. Hopefully some years from now they will both grow up.
How did it get to this state? One reason was attitude, another was timing, a third the participants. The way W3C works may also have had an influence. Many at the time believed that the Web was fundamentally broken, that it was better to have a fresh start. If the Web was broken, what was the point in integrating with it? Whenever SVG integrated with other specs, it was always to other new and still largely unused specifications. SVG wasn’t to enhance the Web, it was to replace it. This was less ridiculous than it might seem now. The Web was war-torn and not in a very presentable state. To this day our Open the Web team is working on, or rather against, the Web of 1999.
The timing was unlucky too. HTML 4 was done when SVG started, and in the following years that group was preoccupied on reengineering HTML to be on top of XML instead of (ostensibly) on SGML. In any case the climate for HTML, W3C’s greatest hit, was chilly. There also seemed to be an implicit W3C assumption that XML made document integration automatic, and then that XML Namespaces would do so.
For one reason or another the browser makers were not involved. Microsoft, that had an SVG precursor in the VML format, has just won the Browser Wars and could go back to sleep for another half decade. Netscape was busy changing its skin to Mozilla. We were turning our CSS browser into a DOM and CSS browser and, more hidden from view, a browser that could thrive in the most cramped devices. The actual SVG implementors didn’t have any great interest in Web integration, for them this was just extra complexity with no direct benefit.
We might have been one of those implementors. In the summer of 2002, mere months after SVG 1.0 was published, our lead SVG developer held an internal demo of a prototype SVG implementation that included the iconic SVG image of the time, the SVG tiger, looking the same way then as it does now. A bare-bones SVG feature set, much smaller than the extended SVG 1.1 Tiny we released in Opera 8, could have been a part of Opera 7. It would have been scalable vector graphics later to be animated, styleable, and scriptable, but not much more. But the great migration towards Presto had started, SVG had to wait. Further on there was a repeat of the Adobe plug-in story, as Ikivo made a great SVG Tiny implementation that covered our phone needs if not our cross-platform needs.
Had it made any difference if we had given higher priority to SVG? For the standards, probably not. The odds were against it at the time, and we had little time to spare for W3C work. It might have increased the browser attention to SVG, but none would likely have come up with an actual implementation faster anyway.
Web developers might have caught on to SVG a little earlier, but they would have been even more frustrated with SVG than they were with HTML+CSS. Today Opera 8 (but not Opera 9) suffers from what I see as a mistake in the specification: If there is anything in SVG a browser doesn’t recognize, it is not allowed to show anything at all. For a hardcore graphics SVG implementation, like the one we were contemplating, that would in practice mean that unless the SVG was specifically made for Opera, we would not have been able to show it.
Another and much larger problem is that even with this rule, which was made with the intent to make different implementations interoperable, the existing SVG products today aren’t really compatible. We will eventually get this right, but it will take years of slog (déjà vu for any CSS enthusiast).
When the SVG world and the Web world eventually did collide, that meeting was often acrimonious. It probably was unavoidable. While there was ideology on both sides to be dealt with, SVG as a standard needed some years on its own to find its standing. HTML, CSS, and DOM is today a fairly harmonious trinity, but that was not the case at the beginning.
Early on Netscape had annexed HTML, CSS came from W3C and got its first real implementation in Opera, and while Netscape came up with JavaScript, Microsoft trumped it with a superior and more popular DOM. Neutral ground W3C DOM (which is more similar to the MS DOM), while formally the standard DOM created by Microsoft and Netscape together, wasn’t really supported by either browser. Mozilla was the first browser to support W3C DOM, followed a few years later by Opera, Konqueror, and most recently iCab. Standards are the first casualty in browser wars, and it took a decade to mend them. But during all this hammering something else happened, the three specs began to fit.
Fitting HTML and SVG the same way should hopefully mean less banging, and the signs are that they are slowly melding, and people from both camps are seing the mutual benefits (and, as many of us are commercial, the business cases). What is more intimidating is that this is going to be the easy part. Uniting HTML and SVG is a bit like uniting magnetism and electicity, there are other forces less mallable to the theory of the Grand Unified W3C.
Jonny, thanks for this great insight into some history of Opera and SVG. I don’t doubt that the specifications will have to learn to play together in the same playground, the benefits are obvious (finally we’ll have rounded corners for divs!).
Thanks Jonny. Very interesting reading about SVG, web standards and implementations.
Cheers for the nice read. Optimist, I see, and fighting with big words and canines :)By the way, why Svensk ?
Sweden is a sleeping tiger, that hits hard when its awaken since it is then in its most irritated state. Sometimes it gets awaken when one plays loud disco music in the street and attempts to dance blocking the noisy traffic and fossil fuel consumption… But oh well then it is just to hit ones heels together three times and cry out lagom… lagom… lagom… 🙂
As a web developer and active surfer I’m wondering – why do we need SVG? Let me explain my position. I’m very optimized person. I like highly optimized software and I make XHTML+CSS as optimized as possible. I do care about traffic and modem users (I’ve got 10 mbits unlimited for myself, but I really care about poor guys with slow connections). When I’m making images I try a lot of options in Photoshop to make them good-looking and smaller in size. Also I use external PNG-compressors to make PNG’s (if some image is smaller in PNG, then let it be PNG!) even smaller. I hope You’ve got the point :). And now… SVG! A textual representation of binary data! It is heavy and no one ever will make nice graphics in Notepad! So why the heck we need SVG? Why not using existing binary formats? Or, maybe, create another one binary. That will save a lot of traffic, that will save some time parsing large text files and so on. I simply don’t understand SVG…
@Aux I think you can appreciate SVGZ, then 🙂
@Aux: There’s also HTTP content encoding.SVG has one major advantage over binary formats, such as PNG. It can be animated, it’s dynamic, it’s “object oriented”. It’s also interactive, by using JavaScript and DOM manipulation, events, etc.That makes up for a very useful graphical format. No, it’s not ideal for everyday usage. Yet, it’s perfect, IMHO, for web applications, for Intranet applications and other “higher” purposes :).
Thanks for the very interesting history lesson. Anyway, good luck on Opera’s quest for full SVG support.
robodesign, I think You know nothing about PNG and binary formats. PNG’s can be animated, multi-layered and so on. It even supports different extensions, so You always can implement Your own image format based on PNG. And for binary – Corel’s EPS (or whatever they call their vector graphics) and Adobe’s AI are object-oriented and, with Adobe, You can manipulate them with JavaScript. So there is NO purpose for SVG.If You want to manipulate images with JS and so on, then look at any image – it is BINARY, but You can get its width and height. So what’s the problem? I think there are NO problems with binary, but real waste of traffic/space exists with SVG.
There are issues with SVG optimisations, but for me the problem isn’t that the format isn’t binary. That would horribly wasteful for a raster image format, but not so much vector formats, especially when considering compression.I see the tools as a much bigger problem. Whether SVG or binary formats they create very inefficient files, only with SVG you can look at the source code and get annoyed because you can see how inefficient they are. There is definitely a market for svgcrunch or something similar.This isn’t just idle bitfiddling. Inefficient vector graphics files will run slowly on desktop computers and not at all on many small devices. PNG extensions like MNG (which I assume you meant, not APNG)aren’t that great performers either. It was supported by Mozilla and then retracted, we considered it around Opera 6 but decided against it. PNG is an extensible format, which could prove useful some day, but that it can be extended doesn’t mean that it will (successfully) be extended. It is like the extensibility of XML, it is very easy to add an element, it is very hard to do so usefully and interoperably.
@AuxI am not here to argue. Yes, I haven’t read the PNG specification. Yes, I am not into binary image formats.Just show me a demo of PNG manipulation within todays browsers, from JavaScript. Without using DirectX in IE, nor canvas in Opera, Gecko and Safari.Thanks in advance.
@jaxYes, you are right. As with (X)HTML, we can see how inefficient is the code generated by the SVG tools.IMHO, the same problem affects Office documents.The precise problem is: today you want something bolded, tomorrow you change your mind, and so on. You basically “damage” the document. All that “noise” is visible in the output code.On top of this is also the tool, which does not effectively remove unnecessary code. Plus, the generated code, during edits, might be stupid too.Artificial intelligence would help. I wonder when we’ll have the first XHTML/SVG/whatever editor with AI.
2robodesignWhat do You mean about image manipulation? If PNG was textual You couldn’t manipulate it either because browsers do not have such functionality (: But if You are really want to manipulate graphics, then You can always load graphics as HTML in iframe and then work bytes. It is lame, but it works. Browser is NOT a Photoshop or Corel Draw, so why do You want to manipulate images? And what can You do with SVG? Nothing serious. Because once again Your browser is NOT a Corel Draw.And actually it does not matter how do You manipulate images – through canvas or what. If it SVG You use another interface and what’s the problem? You don’t like word CANVAS?2jaxI think that SVG clearly shows how XML can go wrong way.About inefficient files. You CAN’T make inefficient BMP or GIF, for example. But You can make such PNG. That depends on format. XML can be VERY inefficient. HTML is the best example. So the thing is to drop XML and to make efficient file format.P.S. I’m not saying – hey guys! Drop SVG support! No! That is NOT my point. My point is to understand why someone out there invented SVG and claiming that SVG is good for web and mobile devices. Good example for mobiles is my mobile phone. It uses SVG for fonts. And it has very limited storage. Several big BMPs without compression with all letters whould take less space. But mobile company thought that SVG is cool. And took my space. I could put another melody there. Or wallpaper. Not everythere we have 100mbit+ connections and 1tb+ hdds.
You can’t make (more) inefficient BMPs because it is a hugely inefficient format to begin with, there is no more space-inefficient commonly used format. GIF at least has compression, and images not taking advantage of that are inefficient.