Re: [SVGMobile12] Comments: Document Structure

Hi Tim,

You wrote:
 > Behavior or default value for unspecified value not given for  
viewBox,
 > preserveAspectRatio, or snapshotTime.

Regarding viewBox and preserveAspectRatio, the default behaviour is  
specified on the attribute definition itself which are linked from  
the section you comment on.

Concerning snapshotTime, it's a hint and the behaviour is User Agent  
dependent.

 > snapshotTime example pictures should have captions.

We have added captions on all examples that were missing one.

 > "rendering tree" - first use of this term in the document, never  
defined.

The specification now includes a definition of the term in the  
introduction section.

 > "To provide some SVG user agents ... conforms to guideline."
 >
 > Why are these couple paragraphs about authoring in the specification?
 > Authors shouldn't be writing their docs for the performance quirks of
 > certain implementations.

This has been removed.

 > The discard element should be moved to the animation section (16)

The WG maintains that discard, while it uses timing, is not an  
animation feature. It is a means for handling the structure for large  
or long running documents. Furthermore we expect it to integrate with  
the pages feature of the Full profile, which is also definitely  
structure oriented.

 > "The 'discard' element itself can be discarded.  It is discarded  
at the
 > earliest: soon after its target element has been discarded..."
 >
 > Not clear from the specification if the discard is always discarded
 > after it fires.  If so, the first sentence of the quote should be  
adjusted.

This has been clarified to state the the discard element is always  
discarded after it has fired.

 > Description of how 'desc' and 'title' content should be
 > handled/presented by a viewer is too vague for interoperable  
implementation.

We have clarified the text to indicate that they are never rendered  
in SVG, but may be rendered in other situations (which are outside of  
the control of SVG, so left vague -- where vague probably means that  
some CSS will be applied to it).

 > "The 'image' element supports the 'opacity' property for  
controlling the
 > image opacity."
 >
 > Explicitly say that fill-opacity does not contribute to the  
rendering of
 > the 'image' element?

We have applied your suggestion.

 > Does the specification want to explicitly forbid/permit the  
incremental
 > display of an image while loading?

It is not specifically forbidden, and we have clarified that.

 > requiredFeatures should theoretically not be needed since all  
conformant
 > viewers will implement all features, correct?  Having this attribute
 > seems to encourage non-complaint implementations.

That is only true if there is only ever one single version of SVG in  
the wild, which obviously is not the case. This mechanism allows  
authors to address that issue by providing fallback. The WG believes  
that this is superior to matching user-agent strings in script.

 > requiredExtensions seems to invite vendor specific non-interoperable
 > extensions.

Extensions are required to be in another namespace, and they're not  
necessarily vendor-specific. Document formats should be extensible,  
and furthermore this provides the means for such extensions to be  
used in an interoperable fashion.

 > ids not used in the prefetch01.svg example and just clutter it,  
likewise
 > prefetch02.svg.

They have been removed.

Thank you very much for your excellent comments, please let us know  
within two weeks if you are not satisfied.

-- 
Robin Berjon
    Senior Research Scientist
    Expway, http://expway.com/

Received on Wednesday, 2 November 2005 13:45:27 UTC