- From: Jon Ferraiolo <jonf@adobe.com>
- Date: Sat, 7 Jan 2006 18:20:55 -0800
- To: "Eric Seidel" <eseidel@apple.com>
- Cc: <www-svg@w3.org>
Eric, I am in 100% agreement about the incongruity of requiring xhtml:img (and CSS background-image) to support SVG content, but saying svg:image does not. In fact, the depth of incongruity is even greater when taking into account the following two facts: * SVG 1.0 and SVG Full 1.1 require that svg:image support SVG content. Thus, if someone is implementing an SVG UA that supports both SVG Full 1.1 and SVG Tiny 1.2, according to the current spec, it is unclear what such a UA should do if it encounters content which has an svg:image that points to SVG content. Should it go into error mode? Render the referenced SVG because it can? Check 'baseProfile', and if it says 'tiny', then not render the referenced SVG? These questions would not come up if SVG-t 1.2 supported SVG content via the svg:image element. * SVG's MIME type is image/svg+xml, which to me would indicate logically that svg:image should be able to reference SVG content. However, the SVG WG has already discussed this issue (repeatedly) and resolved to disallow svg:image to reference SVG content within SVG-t 1.2. The rationale is documented in previous Last Call feedback from Yamakami-san of ACCESS. Yamakami-san's comment was as follows (http://lists.w3.org/Archives/Public/www-svg/2005May/0174.html): --------------- (a-1) differentiation between image and animation in 5.7 The 'image' element Now, SVGT1.2 specifies animation instead of image in Section 5.7. It brings some concerns in a backwardcompatibility. It also poses some confusion that "image/svg+xml" are used consistently in SVGFull1.1 and SVGTiny 1.2, but it is not "image" in SVGTiny1.2. --------------- The official response from the SVG WG (http://lists.w3.org/Archives/Public/www-svg/2005Nov/0192) was: --------------- C) Looking at the SMIL 2.0 specification, it became clear that SVG 1.1 should not have used an image element to point to animated vector graphics content; SMIL differentiates between static raster and animated vector graphics. In SVG Tiny 1.1, only raster graphics were pointed to with the image element. SVG Tiny 1.2 continues that, and adds the missing animation element for animated vector graphics. Also in SVG 1.2 there are further differences, regarding whether an element is timed or not, whether it produces a viewbox or not, whether clipping is needed (raster graphics cannot have content outside their pixel extent, while vector graphics can have content outside their viewbox). In consequence, we believe the division of functionality between the image and animation elements to have been a wise one. We agree that the primary types for IETF media types are sometimes confusingly named - for example double-byte text does not fit within their text type, the requirements for the video type encompass some things that are not really video, and application is used for many things including text and graphics. --------------- Jon From: Eric Seidel <eseidel@apple.com> Date: Wed, 28 Dec 2005 15:44:53 -0600 Message-Id: <35CA6E6F-EEA2-4BC4-B115-5BDA5A611646@apple.com> To: www-svg@w3.org == This message seems to have died somewhere in transit, resending. == As an addendum to (and further justification of) my earlier comment requesting that <svg:image> support referencing whole SVG content. It seems silly to me that Conforming SVG viewers (as stated in Appendix D) must be allow <xhtml:img> to reference a whole SVG document but not <svg:image> Please correct or clarify this area of the spec per my previous email. Thanks, Eric
Received on Sunday, 8 January 2006 02:21:07 UTC