W3C home > Mailing lists > Public > www-svg@w3.org > December 2005

RE: SVGT 1.2: SVG fragment identifiers

From: Doug Schepers <doug@schepers.cc>
Date: Fri, 30 Dec 2005 19:28:08 -0500
To: "'Maciej Stachowiak'" <mjs@apple.com>, <www-svg@w3c.org>
Message-Id: <20051231002810.CF975109EAC@pilfer.dreamhost.com>

Hi, Maciej-

Maciej Stachowiak wrote:
|
| 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.


I agree. If the viewBox or extent of the rootmost 'svg' element does not
include the element addressed by the fragment identifier, the logical and
practical effect of such linking should be that the viewBox is adjusted to
bring the target element into view. If this is indeed the intent of the
current Spec, it is unclear, and the Spec should be revised and clarified.

The manner in which the target element is displayed is also undefined.
Obvious options would be:

1) a minimal shift of the viewBox in the direction of the target element,
such that the entire element (including child elements) is brought into
view;

2) a shift of the viewBox such that the target element it positioned at the
top left of the viewing area (this is most closely analogous to the behavior
of fragment identifiers in HTML, though it's my least favorite option);

3) centering the viewBox on the centerpoint of the target element, at the
zoom level defined by the rootmost 'svg' element; 

4) centering the viewBox on the centerpoint of the target element, at a zoom
level that allows the entirety of the target element's bbox to display (my
personal favorite).

Syntax could be devised to allow for these most common use cases, such as:
 MyDrawing.svg#rectId(center)
 MyDrawing.svg#rectId(center, bbox)
 MyDrawing.svg#rectId(origin)
 etc.



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

I don't think that anything in the passage quoted dictated terms for any
other languages. I think HTML was used as an example because HTML is
overwhelmingly the language used for linking on the Web, and it provides
context for the inward linking mechanism about to be described.


| 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. 

I think those are all good things to consider, and would welcome their
mention as informative examples, but I think that's implied by the text as
it stands.


| 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.

I think that's exactly what it's doing. That's the way I read it, at least.


Regards-
Doug

doug.schepers@vectoreal.com
www.vectoreal.com ...for scalable solutions.
Received on Saturday, 31 December 2005 04:01:14 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:32 GMT