FWIW - I generally agree with Maciej's perspective. In the early days of SVG when I was authoring many of the proposals that (after discussion and subsequent modification) ended up in the SVG spec, what I was thinking was that HTML and SVG shared all of the same infrastructure (e.g., scripting, styling, eventing, DOM, hyperlinking), and most definitely the same events and event attribute, but were separate languages. Truthfully, I had the HTML and PDF specs open on my desk, and I took the graphics model from PDF and pretty much everything else from HTML. In my mind, the key area of difference was that HTML was about flowable documents organized into paragraphs whereas SVG was about bottom-to-top painting onto a canvas. One key part of infrastructure that I was hoping would be shared would be the timing and animation features (and ultimately video and audio) features, such as what Microsoft did with XHTML+Time, but I don't see much momentum in that direction. For the most part, the places where SVG differs in the *infrastructure* versus HTML were not intentional, at least relative to what I was thinking way back when.
The SVG language design was such that it was expected that there was a distinct SVG module that processed the <svg:svg> subtree. One key reason in my mind for having SVG as its own separate thing was that it would allow for dedicated tools (e.g., Photoshop authors raster, Illustrator authors vectors). At this point it would be too hard to attempt to make HTML and SVG into the same unified language. Maybe it would have been better back in 1998-2001 if SVG were designed as new tags within HTML, but that's not what happened, and given current implementation status (Opera, WebKit, and Mozilla all support SVG now, plus all of the mobile implementations of SVG and the implementation of SVG in J2ME), it would be better to do evolutionary improvements to make the combination of HTML+SVG(+Canvas) better rather than attempt a revolutionary set of modifications. Incidentally, I would support the inclusion of incremental SVG enhancements within the HTML5 effort, such as merging Canvas and SVG such that SVG was the declarative markup for Canvas, which would mean such things as adding to createImageData() and getImageData() to SVGImageElement. I haven't thought much about this, but it seems like a good general direction. Jon Maciej Stachowiak <[EMAIL PROTECTED]> Sent by: To public-webapi-req Ian Hickson <[EMAIL PROTECTED]> [EMAIL PROTECTED] cc Doug Schepers <[EMAIL PROTECTED]>, Web API public 05/28/08 12:55 AM <firstname.lastname@example.org> Subject Re: Event handler attributes (Was: Dependencies in XHR) On May 27, 2008, at 11:56 PM, Ian Hickson wrote: > > (In particular, I think we really need to get over the concept of "but > that's a host language issue" or "that doesn't belong in my spec" > and so > on -- we're defining a single platform here, it isn't useful for us > to be > declining responsibility over the more complicated parts. While the > theory > of orthogonal technologies would have been nice, the Web is at a point > where all the technologies are embedded in each other to some > extent, and > we should embrace that, not try to deny it. We will have a healthier > technology stack if we consider the HTML and SVG specs, say, to be > different chapters of the same language spec, rather than if we > consider > them to be separate languages.) I strongly agree with this sentiment. I strongly prefer if similar concepts shared between SVG and HTML can be defined in a consistent way in a single place. I would say many parts of HTML5 arguably fall in this category and I am ok with them being in HTML5 mainly as a matter of expediency, and I hope that in time these things can be factored out. Every little thing like this that is different is a point of pain for implementors of and authors in the emerging Web platform that includes both HTML and SVG. If any such items can be factored sooner rather than later, then that will be welcome news. I apologize also for the item I volunteered to factor out but have not taken to completion (the Window object). It turned out to be a lot harder to do than I expected going in. Regards, Maciej