bestkungfu weblog

On implementing SVG

Filed in: Web, Thu, Jul 8 2004 12:13 PT

Dave Hyatt has mentioned over the last week that Apple has joined the game of extending HTML 4.01, following a long line of others who have attempted same.

Some of this stuff is benign, and probably easy to find in lots of rendering engines. Things like contentEditable don’t give me heartburn. And I generally don’t care whether Safari’s rendering engine supports slider bars as a convenience to an internal consumer (Safari RSS), either. No, what is really getting me about this whole thing is the canvas element, which was added for Dashboard — an enhancement that, to me, really should be in SVG.

There is a lot of hand-wringing going on about what to make of the WHAT working group. I think it’s pretty simple, really: Apple, Mozilla and Opera are squeezing what they can out of their existing codebases. They’re deeply invested in HTML 4.01, and in all the hacks and intricacies that come with rendering it, because they’ve been working at it for years. That’s why they favor incremental progress and consensus hacks over wholesale change. The common belief across the developers in all three companies is that HTML 4.01 is what they do well, it’s good enough, it’s the bread-and-butter of their rendering engines, and that’s all they want to build on. Where that leaves those authors who are clamoring for XHTML is anybody’s guess. It seems they may end up floating into the XML world to find what they’re looking for.

But that position does color their stances on things like, say, XForms, SVG, and XHTML 2. They don’t want to do any of it, because it means work and instability. I only bring this up because I’d rather hear them say this than see them drag the W3C through the mud for daring to develop something other than HTML 4.01.

By the way, and I may just be watching too much of the Tour de France lately, but it seems to me that in the WHAT working group, Mozilla, Opera and Safari are forming a drafting line: they’re staying together closely enough to form a competitive advantage. That’s good business for them, the stuff of game theory. But it leaves them vulnerable to the critique that they’re really a cartel of their own.

Hyatt explains his reason why Dashboard isn’t done in SVG:

A second complaint leveled against us was over the canvas tag, namely that it should have been done using SVG. My response to this is simple. Go to the w3c Web site and print out the SVG specification. Twenty minutes later, after you’ve killed a few dozen trees, then maybe you’ll have an appreciation for why this wasn’t practical.

Hyatt is, of course, neglecting to mention that, alongside the KHTML engine Safari is based on, there is a KSVG engine. They wouldn’t have to reinvent the wheel to use that any more than they did to integrate KHTML. What’s more, an SVG-based interface would allow authors to create pixel-perfect interfaces in Adobe Illustrator, among other tools. How can that not be seen as an attractive feature to a Mac audience?

When Hyatt asked about Web standards in May of last year, he got over 300 responses — of which SVG was the request of perhaps half. If there’s an answer for not, say, implementing KSVG, particularly in such an obvious application, I’d love to hear it.

13 responses to “On implementing SVG”

  1. […] accessible output. Especially relative to the development effort necessary to do it. (Hmm. A pattern.) They say they don’t […]

  2. Dean Jackson says:

    It’s also worth noting that there are profiles of SVG that are very small and much easier to implement. SVG Tiny is implemented on mobile phone handsets from Nokia, Sony Ericsson, Sharp and Siemens (and others) — systems which do not have the support of a G4 processor, the most advanced OS graphics API around and a great framework like Cocoa (providing an XML parser, Javascript engine, etc).

    Dave mentions the SVG specification is verbose and therefore too difficult to implement. I agree that the SVG specification is huge, but that is because it goes into a lot of detail about how you should implement, as well as having a lot of examples. Imagine how big the specification for implementing an HTML browser would be, complete with all the quirks and examples for getting compatibility with IE when you get dodgy content? Would it be better for SVG to have a smaller spec that didn’t give implementation advice (just test against lots of implementations until you can work out what is going on)?

    Having said this, to me the argument for SVG in Dashboard really is that it is a better technology solution than <canvas>. Dashboard chose to use HTML+JS for its Gadgets. This is a document model, similar to SVG — You store your application state as part of the document (using firstly the markup, and then the DOM API). However, <canvas> is an immediate mode drawing API, which means that the programmer has to manage all state between screen updates using their own data structures. This is a completely different paradigm for applications, and completely different from the way people will be developing the HTML+JS side of the gadgets. Using <canvas> you can’t getElementById of a graphical object and change the colour from red to blue; You have to have created your own data model and then redraw the entire canvas at the lowest level. In the majority of these gadgets, the document model is what people will want, mostly because they are comfortable with it, and it has proven to be a very useful model for applications.

    This doesn’t mean that immediate mode drawing is useless. In fact, I really think SVG needs something like this, especially in the cases where you want to draw a huge number of objects but not keep track of them (ie. store them in your DOM).

    Going even further, what application developers should really use for gadgets is a binding/behaviour language for Web Content like XBL. If you are manipulating a stock chart, then it makes more sense to be interfacing with a <yourns:graph> element than with either <svg:polyline> or <html:canvas> and a bunch of JS method calls. XBL also provides an incredible accessibility benefit, exposing the higher-level semantics to the user and developer. We’re still a ways off this, but since Dave is the author of XBL I’m pretty sure he has plans for implementing it 🙂

  3. Ian Bicking says:

    It’s not just Apple, Mozilla, and Opera that are invested in HTML 4. Their investment is dwarfed by the investment of everyone who *uses* HTML 4. HTML 4 *is* the web. I think the reaction against W3C that WHAT has engendered is from web developers who suddenly realize that it’s not that hard to address the problems they care about, and who are a bit annoyed to realize that W3C hasn’t done anything for them for years.

    The W3C doesn’t deserve all the blame for the lack of practical progress (maybe that belongs to IE ;), but W3C hasn’t been a leader either.

  4. Photo Matt says:

    Matt May on SVG
    Matt May on Implementing SVG: “Hyatt is, of course, neglecting to mention that, alongside the KHTML engine Safari is based on, there is a KSVG engine. They wouldn’t have to reinvent the wheel to use that any more than they did to integrate KHTML.” M…

  5. John says:

    Hyatt is right on the point that many Microsoft bashers are not in touch with reality, but he also seems to be one of them. Three guys form some sort of informal group and they don’t invite Microsoft? Mozilla has this XUL support. In my web apps I always support mozilla and IE, but I never supported XUL because it doesn’t work in IE. Anything that doesn’t work in IE has zero chance of being accepted, of course mac zealots, linux zealots and all other Microsoft bashers will say otherwise, but they will not implement support for whatever WHAT group comes up with.

  6. Ethan says:

    Interesting that there was apparently some discussion with Dave Hyatt about an OSX port of KSVG before this whole brouhaha happened. I’d love to hear what came of that exchange.

  7. Matt May says:

    My understanding of the WHAT WG is that their specs are designed to degrade gracefully under IE, so they have that bit covered.

    There are a few ways to spin the Microsoft thing. I don’t know whether MS was invited to participate in WHAT, but I have to believe they were. But the key bit is who has the capacity to execute these specs in code. These guys are implementing Web Forms 2.0 this year, no matter what, and they don’t want to risk their code investment. That’s fine. It’s not W3C’s strength to bang out specs in six months. But in a larger sense, it may not be the greatest thing for the Web to treat a spec built in this manner as a “standard,” either.

  8. karl dubost says:

    About what is a standard, I have given my impression about standard = social thing. The problem of all of that is that in the end it will not benefit to anyone at all: It could happen that it ends with three groups:

    – W3C members implementing XHTML 2.0+XForms+SVG
    – WHAT (Opera, Mozilla, Apple) implementing an hypothetical “HTML 5.0”
    – Microsoft implementing a complete new technology that they are designing right now.

    Oh… no! If I was very saccarstic and naughty, I would say two groups, because when the new market share of the third will be established 3 or 4 years later, the WHAT Group will implement the small bits of it.

    There is certainly a problem of dialog in the Web community, but I’m very careful when it comes to the voice of a few developers and not the Web community as large.
    – Simple Users
    – Web Developers
    – Web Designers.

    So far we heard a lot of about W3C lovers (zealots I should say… :p ) and Browsers developers.

    The WASP has voiced already a negative opinion about the extension temptations.

  9. Isofarro says:

    I’m interested in the field of web applications for two reasons – I work for a company with an e-commerce presence, and I’m interested in web based applications with the idea of a pervasive “desktop”.

    The W3C web applications and compound applications workshop seemed to me to make one thing quite clear: the browser is dead, so the group will start describing a new application / framework.

    What interested me in the WHAT WG roadmap was the continued use of the browser as an application platform. It is feasible now – look at GMail (albeit an accessibility nightmare). With a few extra bits and bobs (XmlHttpRequest and some form of local storage), the browser can be an excellent starting point.

    Launching a web technology that doesn’t work / or want to work in a browser doesn’t make sense to me. The browser is the centre point of the web – people associate the browser with the Web – that was what made the Web as popular as it is today.

    Starting a new platform/application for web applications means starting to convince people to use another World Wide Web – not the same one they’ve been using. Its going to be a tougher sell this time round because people already know the Web by what they see in their browser.

    I am sceptical about the real world value on the Web of the W3C proposed direction. I can see the value of it on intranets and strictly controlled environments, but on the Web iteself it doesn’t make sense to introduce another “browser”.

    That’s why there’s a pushback to the W3C web applications workshop. Its a direction that will take years to gain significant adoption on the web: The W3C have to release something as a Recommendation, then it needs to be implemented by software developers, then there’s a need for killer-applications to encourage adoption by web users. That’s going to take a rather long time. IMO, too long.

  10. karl says:

    If we consider that small applications on a platform are “virtual devices”, I wonder if CC/PP could be used to help the intercommunications between the tools.

    It could help to solve a lot of interoperability problems.

  11. Chaals says:

    Interesting to look back at this. We just released Merlin Technical Preview 2 with widgets – you can use SVG (because we implemented it a while ago), canvas (we do that too), Webforms 2, HTML, XHTML, WML, …

    It will be interesting to see what people use to develop widgets. Like Dean, I think there is a place for both canvas and SVG because they do different things. And HTML and XHTML have their places, too. It is a shame that IE apparently still have no plans to support XHTML (real XHTML).

  12. Ethan says:

    Interesting that there was apparently some discussion with Dave Hyatt about an OSX port of KSVG before this whole brouhaha happened. I’d love to hear what came of that exchange.

  13. […] Updated. Matt May on Implementing SVG: […]

Powered by WordPress (RSS 2.0, Atom)