Re: SVGT 1.2: SVG fragment identifiers

Hello www-svg,

Maciej Stachowiak <mjs@apple.com> wrote:
> "When a source document performs a link into an SVG document via an  
> HTML [HTML4] anchor element (i.e., <a href=...> element in HTML) or  
> an XLink specification [XLINK], then the SVG fragment identifier  
> shall specify the initial view into the SVG document, as follows:
> 
> ?     If no SVG fragment identifier is provided (e.g, the specified  
> IRI did not contain a "#" character, such as MyDrawing.svg), then the  
> initial view into the SVG document shall be established using the  
> view specification attributes (i.e., viewBox, etc.) on the 'svg'  
> element.
> ?     If the SVG fragment identifier addresses any element , such as  
> MyDrawing.svg#rectId), then the document defined by the rootmost svg  
> element shall be displayed in the viewport using the view  
> specification attributes on the rootmost svg element. "
> 
> Issues:
> 
> 1) Are these points actually calling for different behavior? What is  
> the difference between "the initial view into the SVG document shall  
> be established using the view specification attributes (i.e.,  
> viewBox, etc.) on the 'svg' element" and "the document defined by the  
> rootmost svg element shall be displayed in the viewport using the  
> view specification attributes on the rootmost svg element."? Those  
> sound like they would be the same initial view to me. Therefore it  
> seems like fragment identifiers that address any element have no  
> effect have no effect.

There was an error in the second point, pointed out by other commentors;
it should be the closest ancestor svg element. (Note that in SVG Tiny
1.2, which does not allow nested svg elements, these are the same;the
difference becomes significant in other profiles which extend Tiny 1.2.

Compared to SVG 1.1 the intervening bullet about svgView fragments was
also inadvertently missing, and has been restored.

> 2) Behavior is not defined for SVG fragment identifiers that do not  
> address an element. This includes both bare names that do not address  
> an element, and svgView()-style fragments. Perhaps the intended  
> behavior is considered obvious, but the spec does not say what it is.

It was indeed considered obvious - since the element cannot be found,
then its the same as the case where there is no fragment. one gets the
initial view of the rootmost svg element.

> 3) It is inappropriate for the specification to talk about specific  
> mechanisms for accessling links in other languages.

It would be, but we don't. The defining specification for SVG fragment
identifiers is SVG. This is true whether the links to SVG are in SVG,
HTML, PDF, WebCGM, or anything else.

To make this clearer we have added "for example" before "via".

>  Consider some of  
> these other mechanisms for accessing an IRI reference to an SVG  
> document that includes a fragment identifier: type in location field,  
> click link in external application that is not using any XML or HTML  
> language for display, assign the window.location attribute via  
> script, use window.open() in script, select bookmark or history item  
> from menu.

The intent was not to exclude those. The intent was to make clear that
links to SVG content, including to SVG fragments, can occur in any
document.

> Instead of talking about what mechanisms in other  
> languages should do, the spec should say what  the SVG implementation  
> must when presented with an absolute IRI reference that includes a  
> fragment identifier.

No. That is not the same at all.

The procedure when a link (with a fragment) to format foo is found in a
document of format bar is well described in the Architecture of the
World Wide Web, Volume 1:
http://www.w3.org/TR/webarch/#dereference-details

So it is entirely correct and appropriate to talk about a link to an SVG
file in a document that is not SVG.

-- 
 Chris Lilley                    mailto:chris@w3.org
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Thursday, 8 June 2006 16:09:21 UTC