W3C home > Mailing lists > Public > www-svg@w3.org > December 2004

Re: Question about forward and backward compatibility

From: Jon Ferraiolo <jon.ferraiolo@adobe.com>
Date: Mon, 13 Dec 2004 21:48:00 -0800
To: Antoine Quint <ml@graougraou.com>, robert@ocallahan.org
Cc: www-svg@w3.org
Message-id: <>

I am confused by your recommendation which seems inconsistent. Why do you 
recommend an "SVG-capable plug-in" for the <embed> and <object> case, but 
recommend the "native SVG implementation" for the SVG top-level element 
case. Aren't these two cases of the same thing (i.e., processing a 
standalone SVG file)? Is it because you believe that animations only happen 
when the SVG content is embedded by a wrapper HTML? My experience is that 
there is likely to be approximately the same percentage of animations 
within SVG documents loaded as the root document as SVG documents loaded 
via <embed> or <object>.


At 08:08 AM 12/13/2004, Antoine Quint wrote:
>Hello Robert,
>On 7 déc. 2004, at 18:15, Robert O'Callahan wrote:
>>3) It has been useful in our work on CSS to prototype our
>>implementation of new CSS features by making the properties first
>>available with a -moz prefix, and then once our implementation is
>>solid enough (which depends partly on people experimenting with our
>>releases), we make the properties available with the standard names
>>too. It's not clear to do something similar with SVG. One option is to
>>initially enable our SVG prototype only via a Mozilla-specific
>>nonstandard MIME type, which lets Mozilla-specific application authors
>>and experimenters play with it, and later (mid 2005 for SVG Basic?)
>>enable it under the real MIME type and for mixed documents, once we're
>>satisfied that it meets correctness, performance and W3C profiling
>>requirements. We're looking for feedback on this.
>I think there are three cases for SVG usage within Mozilla:
>(1) SVG is referenced from HTML with an <embed> or <object> element. This 
>is the case of many documents on the web today, and a sizeable ammount of 
>that content uses SVG features like animation and declarative 
>interactivity that are not supported by the Mozilla native SVG 
>implementation yet. In this case, I'd recommend handling of the SVG 
>content by an SVG-capable plug-in as a priority, and fallback to the 
>native SVG codebase if none is available. I think this offers the best 
>user experience for backward-compatibility. I also think a preference 
>available through the UI should allow advanced users to change that behaviour.
>(2) SVG is used within a compound document (mixed-namespace). There aren't 
>a lot of documents around yet using this approach, at least not a lot 
>expecting a predictable rendering. Mozilla SVG here offers a breakthrough 
>opprtunity to author rich compound documents with all the great XML 
>vocabularies natively implemented in the Mozilla platform. In that case, 
>the native SVG support should always handle the SVG contents.
>(3) SVG is the top-level element. I also recommend the native SVG 
>implementation to handle the SVG in that case.
>Antoine Quint <aq@fuchsia-design.com>
>W3C Invited Expert (SVG and CDF)
>SVG Consulting and Outsourcing
Received on Tuesday, 14 December 2004 05:49:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:04 UTC