Is this thing on?

SVG Animation (based on SMIL) and CSS Animation offer some similar features for animating Web content. Harmonising these two technologies has been considered on a number of occasions but a path forward has yet to be established. In response to a feature-by-feature comparison of the two technologies the question was raised, “What are the animation features required, prioritised by use case?” (Meeting minutes which lead to Action-48) although a closely related question was, “What would it take to make CSS Animations achieve feature parity with SVG Animations?”

From face-to-face meeting on Web Animations, as discussed here. There is now a CSS-SVG Effects Task Force activity on this.

It has taken time, but by now CSS and SVG are on the same team, which is kind of a precursor to make the specifications well-integrated as well.

The last W3C working group I participated in, Multimodal Interaction (MMI), is at the periphery of the Web and is unlikely to make much of an impact on it in the foreseeable future. However they have produced a few interesting specs (and a few uninteresting frameworks), one of which I will return to in much greater detail later.

The most obscure one may be InkML. The name might imply a language for tagging with paint, but is really describing the set of movements registered by a touch-sensitive tablet or screen so that the scribbles you make can be processed and enhanced by someone more clever than the tablet driver. Unfortunately this specification is made by a tablet-maker subgroup that like Schrödinger's cat is living or dead depending on your perception, and the spec is progressing at a less than vital speed.

Read more...

There is one basic document functionality that none of HTML, CSS, nor SVG can do. None can represent one box, another box, and a link between the two.

Read more...

2005 was the year Mobile SVG arrived, and 2006 was the year Mobile SVG got lost. Before 2005 SVG was used in a few niches, "semantic graphics" like map applications with a limited number of users but really nothing to talk about. In 2005 on the other hand the phone world showed interest in SVG, and while other SVG events happened like the first public alpha implementation of SVG in Opera and Firefox, and pre-alpha in Safari, the Canvas spec, and ominously the Merger of Macromedia and Adobe, everything newsworthy was related to phones.

Not so 1996. The phones were set to mute, and SVG hit the Web. Behind the scenes in 1995 and much more publicly in 1996 there were cultural and technical conflicts with other Web formats, particularly CSS and the new Canvas, with Adobe Flash and Microsoft in the background. This year Opera started to matter in the SVG world as the first useful integrated SVG browser with the release of Opera 9, with the promise of Firefox and Safari. The SVG 1.2 specification reached Candidate Recommendation, being both too early and too late.

The bomb, though expected by the people in the know, was Adobe's discontinuation of its SVG viewer plug-in, the dominant SVG viewer. It was the way to show SVG in any browser (which for most users means the Internet Explorer browser), and though as Adobe had paid good money to buy Flash, the terms struck everyone as stunningly harsh, if not directly hostile to SVG: By the first announcement the plug-in would be gone and unavailable by the end of this year. Later Adobe relented giving the plug-in a longer lease of life, you can download the unsupported plus-in next year too. This was obviously taken as bad news, but personally I think this is advantageous in the long run, much like when AOL Netscape ceased ownership of Mozilla. This was commonly seen as the end of Mozilla, but I thought it was more likely to be the beginning and was proven right. Sugar daddies are only advantageous to a point. Worse than the loss of ASV is that authoring products like Illustrator are unlikely to provide useful SVG support.

Symbolic, but still, the year ended with good news for SVG. By Christmas the first game console, and a hugely popular at that, supporting SVG was released through the Opera beta for Nintendo Wii. I have been sceptical about how useful SVG really is for phones, game consoles seems a better match.

What about this year? I expect 2007 to be a fairly quiet year. Browser support will improve incrementally, the work with finding a replacement for Adobe SVG Viewer will continue. An unknown is whether Microsoft will provide SVG support one way or another, but I don't expect they will. We have begun adding SVG articles on our developer site, and fundamentally developer support is the make or break for SVG. But that is more a challenge for 2008 than for 2007.

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.