- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 20 Mar 2006 14:28:33 -0800
- To: Ola Andersson <Ola.Andersson@ikivo.com>
- Cc: www-svg@w3.org, eseidel@apple.com
On Mar 20, 2006, at 4:48 AM, Ola Andersson wrote: > Hi Maciej, > You make good points. Here are my (personal, not WG) take on this > issue. > > > Incompatibility, you say "this change is incompatible with SVG 1.1." I > don't agree: > SVG 1.1 Full requires <image> to support png, jpg and svg. > SVG 1.1 Tiny requires <image> to support png and jpg. > SVG 1.2 Tiny requires <image> to support png and jpg and does not > allow > <image> to support svg. > SVG 1.2 Full will require <image> to support png and jpg and will at > least allow <image> to support svg (since it must be backwards > compatible). > > It is no incompatibility here; old profile content will render the > same > in new profile viewers. Conformant tiny profile content will render > the > same in full profile viewers as in tiny profile viewers. All right, let's forget about whether there is a compatibility issue in the strictest sense. The situation is: - SVG 1.1 Full requires <image> to support SVG - SVG 1.1 Tiny does not require <image> to support SVG, but does not forbid it either. > Even if <html:img> supports svg I don't see what that have to do with > <svg:image>, why does <html:img> and <svg:image> have to support the > same things? I don't think there is a hard requirement of consistency, but there is at least some evidence that the WG thought at some point that SVG is an image type. > The big difference between <animation> and <image> is that one has a > notion of timeline and the other not. So animated content should be > referenced by <animation>, whether it is svg, flash or animated gifs. That seems reasonable. As you suggest, the true distinction should be animated vs. not, rather than vector vs raster (or SVG vs non- animated raster). There is also the issue that some content types are sometimes animated and sometimes not. Examples would be GIF and SVG. It makes sense to me that you could put these *either* in an <animation>, if the particular item you are using is animated and you want timeline control, *or* in an <image> if this particular resource is not animated and you don't care about timeline control, but merely want to use it interchangeably with other images. Arguably, though, animated GIFs should go in <video> instead of <animation> if you want timeline control. > Static content like png, jpg or PDF should be referenced by <image>. > This is how SMIL specifies it and this makes perfect sense to me. The last draft of the spec doesn't seem to allow this for PDF. > To have <image> (which isn't a timed element) reference animated > content is > not optimal. You would have to specify, for every animated format, how > to create the 'still-image' from the animation. For frame-based > formats > maybe the first frame, for time-based formats, maybe time 0. But note > that for svg1.1 it is not time 0 that is used but rather a special > rendering path where all animation elements are ignored. For some > formats (like svg 1.2) you would like to use the snapshot specified by > the content. Yet another option is to allow <image> content to still animate but with no control over the timeline. But either that a specification for how to get a still image (frame 0, time 0, or as specified by the content type) would be a great improvement. > I think the specification should be changed to say that <image> is for > static content and <animation> is for animated. We should remove the > requirement that <image> is for raster formats only. We should require > <animation> to support svg, but make it clear it may support other > animated formats. I would agree with this change. > I would be ok with removing "SVG Tiny 1.2 does not allow an SVG > document > to be referenced by the 'image' element" if that would please someone > (note that svg full 1.2 will allow this anyway). I would agree with this change as well. > I would not be ok with *requiring* SVG Tiny 1.2 to support svg > referencing from <image>. To require a tiny viewer (that must run on > very constrained platforms) to support static svg rendering would > force > the tiny viewer to increase memory footprint with a functionality that > isn't required. If static images of animated svg indeed would have > been > a requirement for svg tiny content the correct way to address it would > have been to add the 'snapshotTime' attribute to the <animation> > element. I don't think it is that big a deal whether it is allowed or required. But if static rendering is even allowed, then it should be specified how to do it when supported. I doubt static rendering support would increase code footprint that much, and could even save data footprint (no need to keep AnimatedAttributes around). > What do you think? It sounds better than the status quo to me. I would like to know what others on the WG think. Regards, Maciej
Received on Monday, 20 March 2006 22:28:49 UTC