W3C home > Mailing lists > Public > www-svg@w3.org > July 2006

Re: [SVGMobile12] Section 14.2 -- What is the difference between "_replace" and "_self"

From: Chris Lilley <chris@w3.org>
Date: Tue, 11 Jul 2006 22:57:56 +0200
Message-ID: <1599534019.20060711225756@w3.org>
To: www-svg@w3.org
Cc: Boris Zbarsky <bzbarsky@mit.edu>

Hello www-svg,

Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Dear SVG Working Group,
> 
> I'm not quite sure what the difference between target="_replace" and 
> target="_self" is for <svg:a> elements.  When do they actually behave 
> differently?

For a stand-alone SVG file, they will not behave differently. All the
browser window has is a single SVG file; following links results in the
linked-to content replacing the SVG file. The displayed content is not
granular; only one thing is being displayed, so only one thing can be
replaced.

The difference comes with compound documents by reference. Multiple
documents are being displayed simultaneously, so the compound document
has some level of granularity. The whole thing can be replaced, or parts
of it.

This can come about in various ways. HTML frames are one way (and
XFrames another). The XHTML object element is a common way; also iframe.
For SVG, the animation element can point to another SVG file. And these
can be nested.

These constructs are what is meant by "presentation context":

  This attribute specifies the name or portion of the target window,
  frame, pane, tab, or other relevant presentation context (e.g., an
  HTML or XHTML frame, iframe, or object element) into which a document
  is to be opened when the link is activated.

The names and descriptions are taken from WebCGM:
http://www.w3.org/TR/REC-WebCGM/REC-03-CGM-IC.html#webcgm_3_1_2_2

which in turn took them from HTML4, although adding better description
and a new value. SVG uses the WebCGM definitions, slightly generalized
from just frames to other types of presentational context.

The names are probably not the most intuitive ones but are historical.

So for example if I have a frame document displaying an xhtml document X
and an SVG document S; and the xhtml document has two object elements,
o1 and o2, displaying SVG files S1 and S2.

Drawing this as a tree, where children are linked from their parent:

F -+- S
   |
   +- X -+- S1
         |
         +- S2


Lets suppose S1 has some 'a' elements (a1, a2, etc).

a1 has target="_self". Traversing this link would result in X being
replaced by whatever a1 linked to. A typical use case for this is the
'imagemap' where the SVG file has a number of links and is used as a
navigation panel or something like that for the xhtml file.

a2 has target="_replace". Traversing this link results in S1 being
replaced by whatever a2 linked to. A typical use case for this is a
series of diagrams (top, side and front views of a house; open and shut
views of some equipment; an overall electrical schematic with detailed
circuit diagrams of particular modules, etc).

a3 has target="o2". Traversing this link results in the object element
o2 displaying whatever a3 linked to. A typical use case for this would
be a graphical overview or navigation structure, which stays put while
other graphics update in response to link traversal.

a4 has target="_parent" or "_top". In either case, for this example,
traversing this link results in the whole frameset being replaced by
whatever a4 linked to. To show a difference between the two, i would
need a more complex example where the entire first example is itself
embedded in a second frameset or iframe or object element or whatever;
in that case, the parent would not be the same as the top.

> This could probably benefit from an example (as well as a test in 
> the test suite, of course ;) ).

This is difficult for standalone SVG files (although it can be done,
using the animation element). We can certainly add an example or two to
the spec and to the test suite.

Probably more useful, though, would be to work with the CDF WG to ensure
that all of these options are tested in the CDF test suite. The main use
case is with compound documents.

> Thanks in advance for the explanation,

Hope it was helpful.



-- 
 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 Tuesday, 11 July 2006 20:58:47 GMT

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