Re: SVGT 1.2: Addendum: <svg:image> support of external SVG content

On Jan 7, 2006, at 6:20 PM, Jon Ferraiolo wrote:

>
> 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):

I disagree with the WG's resolution. I think the two reasons you  
stated are strong reasons for not disallowing it, and outweigh  
whatever the SMIL 2.0 spec says. SVG does not use elements from the  
SMIL namespace so it seems to make no practical difference, whereas  
the inconsistency with requirements on XHTML and CSS, and with SVG  
1.1, do.

The actual text in the psec is also unclear on what exactly is  
disallowed:

"In SVG Tiny 1.2, the 'image' must reference content that is a raster  
image format, such as PNG and JPG. SVG Tiny 1.2 does not allow an SVG  
document to be referenced by the 'image' element; instead, authors  
should use the 'animation' element for referencing SVG Documents.  
Conforming SVG viewers must support PNG and JPEG image file  formats.  
Other image file formats may be supported."

The "must" here sounds like a requirement on the document, not on  
user agents. Is it meant to be a UA requirement as well? It's also  
unclear whether other vector (but non-animated) image formats should  
be allowed. For example, would it be legal for an <svg:image> element  
to reference PDF content, if the UA supported this?

Perhaps it would make more sense to specify that when an SVG is  
referenced as an image (via <xhtml:img>, <svg:image> or CSS  
background-image) it should provide only static rendering  
capabilities, without animation or scripting (the "Conforming Static  
SVG Interpreter" level of support). This would be a more sensible  
requirement in the XHTML and CSS case (DOM scripting inside CSS  
background images is a scary concept) and would not create any  
semantic difficulties for <image> vs. <animation>.

I'd like to ask the SVG working group to revisit this issue.

Regares,
Maciej




> ---------------
> (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 05:08:52 UTC