Re: SVGT 1.2: <image> does not support SVG

On Mar 17, 2006, at 6:35 AM, Ola Andersson wrote:

>
> Hi Eric,
> It would probably not be hard to support svg as an image type but we
> prefer to use <image> only for still raster images and use <animation>
> for animated vector graphics sine this is in line with SMIL and  
> makes a
> nice and clean separation between the two media types.
> See
> http://www.w3.org/TR/2005/REC-SMIL2-20050107/extended-media- 
> object.html#
> edef-ref


Hi Ola,

I think the SVG working group should reconsider this decision. The  
current element names and content limitations do not effectively  
express the needed semantics. The current definitions are that that  
<image> is a "raster image format" and <animation> is an SVG

Here are some use cases that are not very well covered by the current  
definitions:

- An animated raster image format, such as animated GIF. Technically  
this should be in <image>, but it seems confusing that the  
animatability of SVG makes it disallowed for <animation> but that is  
not the case for GIF.

- A non-animated vector image format, such as PDF. Safari/WebKit  
support PDF as an image format in HTML, and it seems like this should  
not be disallowed for SVG. But since <image> only allows raster  
formats and <animation> only allows SVG, we would have to forbid this  
to comply with the spec, and no SVG implementation could allow it  
except via <foreignObject> which provides a much weaker degree of  
integration than <image> or <animation>.

- An animated vector image format that is not SVG. Right now I don't  
know of any SVG implementation supports such formats directly, but  
suppose an implementation directly handled the Flash file format. It  
could not be used as either an <image> or <animation>.

- A generic image viewer that would like to ignore the differences  
between vector and non-vector images, and simply display an image  
collection. For example, suppose I make a CGI script that finds a  
random image on the web and redirects to it. Now I want to make an  
SVG document that includes 40 such images, just by having 40 <image>  
elements with appropriate size and placement. But, whoops, that won't  
support SVG. In fact, there's no reasonable way to do this in a way  
that makes SVG and other image formats interchangeable. Sometimes an  
image is just an image! But now we can't treat something like <http:// 
www.croczilla.com/~alex/old-site/tiger.xml> as an image.

On top of that this change is incompatible with SVG 1.1. And the spec  
actually requires implementations that support both HTML and SVG to  
support in the HTML <img> element.

These all seem like serious problems. The working group had better  
provide some strong arguments for creating these kinds of limitations  
and inconsistencies. So far I have heard the following arguments:

* It makes a clean separation between images and animations
    BUT: I think my examples show it clearly does not!

* The Working Group already voted
    BUT: This is not a technical argument and not an appropriate  
response to a Last Call comment. The WG is obligated to formally  
respond with a technical justification.

* Aligns better with SMIL
    BUT: Since SVG incorporates SMIL features via advanced copy and  
paste technology and already has incompatible differences, it's not  
clear why it should outweigh the specific technical problems above,  
the differences with what the spec requires for HTML, and the  
incompatibility with SVG 1.1. It's not obvious how any real problems  
are solved or how any software will work better due to this.

Given this, I do not think the WG's response on this issue is adequate.

I will leave it to Eric to state whether he is satisfied with the  
resolution.

Regards,
Maciej



> Thanks for the review
> /The svg wg
>
>
> ----
> From: Eric Seidel <eseidel@apple.com>
> Date: Tue, 27 Dec 2005 22:10:44 -0600
> Message-Id: <A0B92CB5-873A-4C5C-B3A6-EEE11BB45C9D@apple.com>
> To: www-svg@w3.org
>
> Greetings,
>
> I found it peculiar that Section 5.7 <image> specifically disallows
> <image> tags from referencing whole external SVG files and instead
> suggests that content authors use <animation> instead for that
> purpose.  If implementors already have to support <animation>'s use
> of whole external SVG files, how can it be any harder for them to
> support whole SVG files as part of <image>?  I would encourage the
> working group to consider allowing <image> to reference entire
> external SVG documents.
>
> Thanks,
> Eric
>
>

Received on Monday, 20 March 2006 05:53:04 UTC