- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sun, 19 Mar 2006 21:52:49 -0800
- To: Ola Andersson <Ola.Andersson@ikivo.com>
- Cc: www-svg@w3.org, eseidel@apple.com
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