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.


             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         <public-webapi@w3.org>          
                                       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.


<<inline: graycol.gif>>

<<inline: pic24019.gif>>

<<inline: ecblank.gif>>

Reply via email to