High-Quality Dynamic SVG Viewer

Hi,

I've mentioned, various parts of this problem in previous messages,
and there's been a fair bit of discussion, however none has realy
resolved my concerns. And so I'm going to explain in more detail my
issues with the Conformance requirements for a "High-Quality Dynamic
SVG Viewer", the problem exists in both the SVG 1.0 recommendation,
and the proposed rec. 1.1.  My apologies for not raising it sooner in
the process but my interpretation of certain parts were so at odds with
what's since been discussed in the mailing lists, that I simply didn't
consider it to be wrong.

The main problem is:

http://www.w3.org/TR/SVG/conform.html#ConformingHighQualitySVGViewers
(and the equivalent 1.1 section)

| A Conforming High-Quality Dynamic SVG Viewer must support
| the following additional features:
|
| Progressive rendering and animation effects (i.e., the start of the
| document will start appearing and animations will start running in
| parallel with downloading the rest of the document).

Exactly what the above means, is completely unclear, and incompatible
with other parts of the specification.

One problem is the SVGLoad event which is described as:

| The event is triggered at the point at which the user agent has
| fully parsed the element and its descendants and is ready to
| act appropriately upon that element, such as being ready to
| render the element to the target device
( http://www.w3.org/TR/SVG/interact.html )

The problem here is that in the dynamic viewer, the SVGLoad event must
fire after rendering, this was clarified when I raised this
previously, and a workable - although out of line with the spec -
interpretation was given. I now believe the spec should be tightened
here to remove the inconsistency.

The next problem is with animation, in
http://www.w3.org/TR/SVG/animate.html we're told "For SVG, the term
presentation time indicates the position in the timeline relative to
the [exact time at which the 'svg' element's onload event is
triggered] of a given document fragment.  Despite the clear use of
Document Fragment here, The interpretation put on this in www-svg
messages is that it is only the root svg element that this applies to,
and there is only one timeline - this is a seperate issue really, but
since it is irrelevant other than to a high quality dynamic viewer,
it's really part of the same.  It also seems odd that the timelines 0
time is before any rendering has been done, this means unless the
rendering is instantaneous a user will not see the initial position,
and position the user first sees is dependant on how long the
rendering takes.

The interpretation from the mailing list means that there can be no
timed based animation before the root SVGLoad fires, which has me
wondering exactly what "animations will start running in parallel with
downloading" means.  If we take other event based animation, I don't
believe this can start either, since from
http://www.w3.org/TR/2001/REC-smil-animation-20010904/#Unifying says
"From a scheduling perspective, the time is described as unresolved
before the activation. Once the element begin or end has been
activated, the time is resolved." so they still have to happen at a
time, but the timeline hasn't started so no time exists. This is from
the SMIL rec though, and I certainly have little experience of it, so
my interpretation may be wrong.  I cannot currently see how it is
possible to have animations before the SVGLoad event if there's only
one timeline, yet a High Quality Dynamic Viewer requires it.

A third problem is with what a viewer does with an invalid document,
consider a missing </svg> from the root element, in this case the
error is on the root element, however
http://www.w3.org/TR/SVG/implnote.html#ErrorProcessing says "The
document shall be rendered up to, but not including, the first element
which has an error" in which case no content should be rendered.  This
is another incompatibilit.

I do not believe that a High-Quality Dynamic SVG Viewer is compatible
with what is specified in the rest of SVG, there are no implementations
that I know of, ASV 3.0 is close, but the SVGLoad events at least do not
fire at the appropriate places.  I believe the simple way of resolving
this issue especially as since as we have no implementation we cannot
hurt anyone, is to remove the High Quality Dynamic SVG Viewer from the
specification. This important requirement can then be revisited in SVG
1.2 where implementaton experience and tight specification can be
provided.

Again, apologies for the lateness of the issue.

Regards,

Jim.

Received on Tuesday, 26 November 2002 11:48:34 UTC