Re: Question about forward and backward compatibility

Chris Lilley wrote:

>On Tuesday, December 7, 2004, 6:15:16 PM, Robert wrote:
>ROC> I'm trying to understand how authors write SVG content that will be
>ROC> compatible across different SVG versions and user agents.
>ROC> 1) Is there a way for authors to write a single SVG file that will
>ROC> take advantage of SVG 1.2 features but degrade gracefully in a user
>ROC> agent supporting only 1.1? It appears not, since the 1.1 user agent is
>ROC> required to visually show error due to the presence of 1.2-specific
>ROC> elements and attributes.
>You should take a look at the switch element and the requiredFeatures
>attribute to see how to do this.
I know about that. My question is, doesn't the letter of the 1.1 spec 
require 1.1 user agents to show error when they encounter 1.2 tags and 
attributes, even if they're under a switch?

>ROC> 2) Given the presence of 'switch' and feature strings, are user agents
>ROC> allowed to implement any SVG 1.1 subset that is exactly the union of a
>ROC> set of feature modules? Or is this now officially deprecated by SVG
>ROC> 1.2 WD section 2?
>Implementing random subsets is not encouraged, no. Recognizing that a
>given implementation might not go from 0% to 100% in its first release,
>we recommend first implementing SVG Tiny 1.1, then gradually improving.
>In addition, some classes of implementation (eg printers, server-side
>transcoders) can usefully be static rather than dynamic (noanimation, no
Unfortunately being SVG Tiny would force us to disable a bunch of 
features but still do animation, which we won't be able to do before our 
next release. But otherwise it sounds like a good idea to me.

>ROC> 3) It has been useful in our work on CSS to prototype our
>ROC> implementation of new CSS features by making the properties first
>ROC> available with a -moz prefix, and then once our implementation is
>ROC> solid enough (which depends partly on people experimenting with our
>ROC> releases), we make the properties available with the standard names
>ROC> too.
>To be clear - in the implementations, not in the specs. I have not seen
>any -css2 or =--css3 properties in the specs.

>I agree that things like -moz-opacity were a good implementation strategy. Batik took a similar
>approach when implementing SVG 1.2 features on an experimental basis (it
>required using a Batik extension namespace and a special build where the
>extensions were recognized).
Why is using an extension namespace better than using an extension MIME 

>ROC> It's not clear to do something similar with SVG. One option is to
>ROC> initially enable our SVG prototype only via a Mozilla-specific
>ROC> nonstandard MIME type, which lets Mozilla-specific application authors
>ROC> and experimenters play with it, and later (mid 2005 for SVG Basic?)
>ROC> enable it under the real MIME type and for mixed documents, once we're
>ROC> satisfied that it meets correctness, performance and W3C profiling
>ROC> requirements. We're looking for feedback on this.
>I would see little value in that; once a specification is a
>Recommendation, its no longer 'experimental'. So, requiring a specific
>mozilla media type would only divide the market.
We'd try to avoid dividing the market by advocating the special MIME 
type just for Mozilla-specific application authors (e.g., XUL authors). 
Think application/xml+moz-vg. We'd recognize the real MIME type (and 
mixed documents) later this year --- before there's much usage, I guess 
--- and encourage Web authors to use it. I understand the special MIME 
type is still suboptimal but everything looks suboptimal.


Robert O'Callahan <>
"Here is a trustworthy saying that deserves full acceptance: Christ
Jesus came into the world to save sinners-of whom I am the worst.
(1 Timothy 1:14-16)

Received on Thursday, 23 December 2004 13:59:49 UTC