- From: Chris Lilley <chris@w3.org>
- Date: Tue, 11 Jul 2006 22:57:56 +0200
- 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 UTC