- 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
Antoine, 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>. Jon 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 >-- >Antoine Quint <aq@fuchsia-design.com> >W3C Invited Expert (SVG and CDF) >SVG Consulting and Outsourcing >http://svg.org/user/uid:2/diary > >
Received on Tuesday, 14 December 2004 05:49:00 UTC