Re: Question about forward and backward compatibility

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
-- 
Antoine Quint <aq@fuchsia-design.com>
W3C Invited Expert (SVG and CDF)
SVG Consulting and Outsourcing
http://svg.org/user/uid:2/diary