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: Boris Zbarsky <bzbarsky@mit.edu>
Date: Sun, 16 Jul 2006 22:52:24 -0500
Message-ID: <44BB0978.50807@mit.edu>
To: Chris Lilley <chris@w3.org>
CC: www-svg@w3.org

Chris Lilley wrote:
>> 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.

OK.

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

Which constructs?  <iframe>s, <object>s, and so forth?  Does "presentation 
context" refer to the DOM Element involved or to some other object?

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

That makes it sound like a "presentation context" is "something you can stick a 
document into".  So the "inside" of an <iframe>, say?  I'm assuming this is the 
case from now on, but if I'm wrong please let me know and I'll adjust my 
thinking as needed.

> 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

OK.  But you're not normatively referencing this, right?  That is, you're using 
your own definitions of "_replace" and "_self"?

> which in turn took them from HTML4, although adding better description
> and a new value.

Yes, the new value is what I'm trying to understand.

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

Sure.  I don't really care about the names, as long as I can tell what they 
mean.  ;)

> 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

Wait.  Why "X" and not "S1"?  Would the behavior be different if <iframe> were 
used instead of <object>?  Note that if <iframe> were used and an HTML file "S1" 
were loaded in the <iframe>, then, in the HTML4 meaning of _self, "S1" would be 
replaced by the linked content, not "X".

I guess this all comes down to a precise definition of the term "the same frame 
as the current SVG image" (though I'm not sure how the "The current SVG image is 
replaced" part of the SVG 1.2 Tiny description of "_self" can be interpreted to 
mean "replace X" in your example.

> a2 has target="_replace". Traversing this link results in S1 being
> replaced by whatever a2 linked to.

This sounds more like what _self does in HTML.

In general, it sounds like your description for _self is what _parent does in 
HTML and your description for _replace is what _self does in HTML.  At least for 
<iframes>.  This does raise the question of whether <object> and <iframe> in 
HTML should behave differently for link-targeting purposes.  In Gecko they do 
not, last I checked.  For example:

<object type="text/html"
         data='data:text/html,
               <a target="foo"
                  href="http://www.mozilla.org">Click me</a>'
         name="foo">
</object>

will behave as your description of _replace.  Similar if I use target=_self.  If 
I use target=_parent, then the document that the <object> lives in is replaced.

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

In that case, I'd really like to see the differences from HTML resolved.

Thanks a ton for the explanation; I hope I understood correctly!

-Boris
Received on Monday, 17 July 2006 03:52:44 GMT

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