Re: SVG Linking Test Case Questions

Maciej, all,

Based on recent discussions and a little more digging, here's what I
think the history/problem is.  I realize I'm no expert here and this
may be incorrect and may confuse further... I seek confirmation or
refute by the various Working Groups, but I'm at a loss as to who
actually owns this issue because it's spread across 4 specifications
(HTML, WebCGM, SVG, CDF).  My money is on the HTML WG to clarify this
issue first because the other specs rely on it.

- the HTML 4.0 spec has a variety of what I'll call "rectangular
document containers":  frame (i.e. FRAMESET), object, iframe, img,
applet

- the HTML 4.0 spec defines the html:a element for links.  The html:a
element has a target attribute [1]

- the target attribute is defined in the Frame section of the HTML 4.0
spec as "the name of a frame where a document is to be opened" [2].
Right away, this seems to imply that link targets can only be HTML
frames or iframes and not just any "rectangular document container",
since this definition is within the Frame chapter of the spec.

- this is further strengthened by [3] which, when comparing object to
iframe, states that "the IFRAME element may be a target frame",
implying (to me) that html:object CANNOT be a target frame.  Thus,
from the spec point of view, html:object does not create a "frame" in
this parlance.  (I'll state right here that I understand that some
user agents have not implemented things this way, I'm just
interpreting the spec at this point)

- the HTML 4.0 spec defines some special names for link targets [4].
The relevant ones for this discussion are:
    - _self, defined as "The user agent should load the document in
the same frame as the element that refers to this target."
    - _parent defined as "The user agent should load the document into
the immediate FRAMESET parent of the current frame. This value is
equivalent to _self if the current frame has no parent."

- when WebCGM came along (2001), it was realized that was incorrect in
the HTML spec.  The html:object element (and html:img?) SHOULD be able
to be the target of a link, so the specification added a _replace
target name that is defined as "The viewer shall replace the current
CGM picture by the designated CGM picture in the same rectangular area
in the same frame as the picture which refers to this target." [5].

- the SVG 1.1 spec describes the svg:a element [6], which functions
very much like a html:a element.  It has a "target" attribute that
"specifies the name of the target location (e.g., an HTML or XHTML
frame) into which a document is to be opened when the link is
activated."  By looking at specifications alone, this seems to be
referring to HTML frames and iframes only.  It seems to mean that BY
THE SPECIFICATIONS there is no way to replace embedded SVG document
via HTML:object with a new document (clicking a SVG 1.1 link with
target="_self" should always replace the HTML frame, by the letter of
the spec).

- in SVGT 1.2, the attempt to remedy this situation was to change the
verbage of the "target" attribute [7] such that it refers to the
WebCGM spec (i.e. which added the _replace value).

- So in Maciej's example:

<object type="image/svg+xml" data='data:image/svg+xml,<svg
xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/
1999/xlink"><a xlink:href="http://www.google.com/"><text x="0"
y="32">click here</text></a></svg> '>

In SVGT 1.2, it seems the intention is:
	- a target="_replace" would put Google's page in the HTML:object's
rectangular area
	- a target="_self" would put Google's page in the enclosing HTML
frame's rectangular area

i.e. "_replace" is a way to make the html:object's rectangular area
look like a "frame", even though the HTML 4.0 implies it is not

- Unfortunately, this sort of clarification resulted in an uproar
because some de-facto implementations of HTML (Mozilla?) always treat
the html:object's rectangular area as a frame.   I note from Doug's
tests [8] that Opera treats the html:object differently if the
embedded document is an HTML document or a SVG document.

- the CDF/WICD spec stated that _self in SVG was not the same as _self
in HTML [9].  Based on my understanding of the specs above, I think
this is an untrue statement.  In both cases, _self is supposed to
replace the "frame" that contains the document.  So we get down to the
definition of "frame" again and de-facto implementations.

I'll be honest - after all the above and looking at Doug's tests [8],
I'm not sure what should be done.  Each UA has their own definition of
what a "frame" is in the context of link targets so someone will have
to change their implementation regardless of what is done.

But clearly the HTML spec is the first thing to clear up.  So I took a
look at WHATWG's HTML5 spec and they use the term "browsing context"
[10].  They explicitly state that the target attribute specifies a
browsing context [11] and that object creates a new browsing context
[12].  According to Doug's tests, IE is not comformant with this.  In
fact, IE seems to be comformant with my above interpretation of the
existing HTML 4.0 spec..

Regards,
Jeff Schiller

[1] http://www.w3.org/TR/REC-html40/struct/links.html#h-12.2
[2] http://www.w3.org/TR/REC-html40/present/frames.html#target-info
[3] http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.5
[4] http://www.w3.org/TR/REC-html40/types.html#type-frame-target
[5] http://www.w3.org/TR/REC-WebCGM/REC-03-CGM-IC.html#webcgm_3_1_2_2
[6] http://www.w3.org/TR/SVG11/linking.html#Links
[7] http://www.w3.org/TR/SVGMobile12/linking.html#AElement
[8] http://vectoreal.com/w3c/link-target-test/
[9] http://www.w3.org/TR/WICD/#link-activation
[10] http://www.whatwg.org/specs/web-apps/current-work/#windows
[11] http://www.whatwg.org/specs/web-apps/current-work/#target3
[12] http://www.whatwg.org/specs/web-apps/current-work/#the-object

On 4/1/07, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On Mar 29, 2007, at 3:31 PM, Chris Lilley wrote:
>
> >
> > On Thursday, March 29, 2007, 11:54:42 PM, Jeff wrote:
> >
> > JS> Chris,
> >
> > JS> I do have one problem though:
> > JS> http://www.w3.org/TR/WICD/#hyperlinking says
> >
> > JS> "NOTE: The keyword _self does not mean the same in SVG as it
> > does in
> > JS> HTML. In HTML it replaces the current document and in SVG it
> > replaces
> > JS> the parent document."
> >
> > JS> Based on what you've written, what Sjeord said - is that statement
> > JS> incorrect?  I believe it is.
> >
> > Thanks for the heads up.
> >
> > Originally WICD was pointing to the wording in the WebCGM spec. Then
> > that was objected to - likely from the same misaprehension mentioned
> > earlier - and the current wording -- which, as you say, is bogus --
> > was added instead.
>
> Which part do you think is bogus, the HTML part or the SVG part? It's
> no longer clear to me what you think he SVG spec says. It is not
> clear to me what it says either, as I can't tell from the spec what
> the difference between _self and _replace is supposed to be, and I
> don't remember the conclusion non-normative mailing list debate about
> this some time ago.
>
> In particular, clicking on the link in the HTML document below will
> replace the frame only. If the target were "_parent" it would replace
> the whole document:
>
> <object type="text/html" data='data:text/html,<a href="http://
> www.google.com/" target="_self">click here</a>'>
>
> Even if HTML4 does not state this clearly, HTML5 definitely will.
>
> Does the SVG spec call for different behavior on the following HTML
> snippet or not?
>
> <object type="image/svg+xml" data='data:image/svg+xml,<svg
> xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/
> 1999/xlink"><a xlink:href="http://www.google.com/"><text x="0"
> y="32">click here</text></a></svg> '>
>
> Your position last time was that it did indeed call for different
> behavior. If it does not, then how are "_replace" and "_self"
> different? Would the difference only be relevant if SVG were embedded
> in an HTML <img> element or an SVG <image> element? Does SVG's
> foreignObject create a frame? The spec as it stands seems to depend
> on a definition of the term "frame" but does not define it, or
> clarify how "same rectangle in the same frame" differs.
>
> Regards,
> Maciej
>
>
> >
> > I will make sure this gets discussed in the CDF WG.
> > JS> Jeff
> >
> > JS> On 3/29/07, Chris Lilley <chris@w3.org> wrote:
> >>> On Thursday, March 29, 2007, 11:18:19 PM, Jeff wrote:
> >>>
> >>> JS> Woops, it seems this is really related to the whole
> >>> target="_self"
> >>> JS> question that caused so much anger in SVGT 1.2.  Only now am I
> >>> JS> beginning to understand the picture, eight months after stuff
> >>> hit the
> >>> JS> fan...
> >>>
> >>> JS> Key Reading:
> >>> JS> http://lists.w3.org/Archives/Public/www-svg/2006Aug/0053.html
> >>>
> >>> Right. HTML 4.0 spec is very poorly worded in this respect; despite
> >>> having a range of elements (frame, object, applet, iframe ...) it
> >>> only talks about one of them for target.
> >>>
> >>> WebCGM 1.0 had better wording, less specific to the frame
> >>> element. SVG
> >>> 1.1 adopted that wording and improved it some more. WebCGM 2.0 took
> >>> *that* wording and improved it a little more.
> >>>
> >>> JS> Basically I agree with Sjoerd.  Now that we have a HTML WG
> >>> again, it
> >>> JS> seems like if the HTML spec was updated to specifically state
> >>> that
> >>> JS> HTML:object creates a "frame" for its content, then it would
> >>> be clear
> >>> JS> what web browsers should do for target="_self" (even in SVG 1.1)
> >>>
> >>> Yes. Ideally they would add the current best wording, or even
> >>> make it
> >>> clearer again.
> >>>
> >>> JS>  and
> >>> JS> certain folks would be a little happier with the SVG 1.2
> >>> spec.  There
> >>> JS> would be no incompatiblity for HTML UAs,
> >>>
> >>> There isn't. That meme grew from some folks misunderstanding "we
> >>> took
> >>> the wording from WebCGM" to mean "we don't care about HTML" or "we
> >>> want to be deliberately incompatible".  Rather than "we want the
> >>> best,
> >>> clearest wrding, and as it happens the HTML 4 spec is unclear and
> >>> inconsistent and doesn't even cover all the elements in HTML 4".
> >>>
> >>> In fact that was cleared up on list (by Sjoerd among others)
> >>> within 24
> >>> hours, but juicy stories like that have their own life in the
> >>> blogosphere and still circulate a year or so later.
> >>>
> >>> JS>  i.e. _replace would always
> >>> JS> mean _self and would match the de-facto behavior exhibited by
> >>> IE and
> >>> JS> Mozilla.  But of course, Opera would have to update its
> >>> behavior to
> >>> JS> match Mozilla's.  Not sure about Safari.
> >>>
> >>> JS> Jeff Schiller
> >>>
> >>> JS> P.S. I have asked to be included in the new W3C HTML effort,
> >>> but am
> >>> JS> waiting for acceptance via email.
> >>>
> >>> That should take less than 24 hours.
> >>>
> >>> JS>   If anyone feels this email will
> >>> JS> help that group, please forward it to the mailing list.
> >>>
> >>> Sure, although its also in a public archive so easy to point to.
> >>>
> >>> JS> On 3/29/07, Jeff Schiller <codedread@gmail.com> wrote:
> >>>>> On 1/12/07, Chris Lilley <chris@w3.org> wrote:
> >>>>>> On Wednesday, January 3, 2007, 7:52:53 PM, Jeff wrote:
> >>>>>>
> >>>>>> JS> 1)
> >>>>>> JS> http://www.w3.org/Graphics/SVG/Test/20061213/
> >>>>>> htmlObjectHarness/full-linking-a-01-b.html
> >>>>>>
> >>>>>> JS> I'm confused by the phrase "should replace the initial
> >>>>>> view of this
> >>>>>> JS> test case in the viewer frame".  When clicking the arrow
> >>>>>> which of
> >>>>>> JS> these alternatives is correct:
> >>>>>>
> >>>>>> JS> a) Entire browser window gets replaced by linkingCircle-
> >>>>>> f.svg (test
> >>>>>> JS> case with explanatory text not present)
> >>>>>>
> >>>>>> JS> b) The contents of the HTML:object frame on the left gets
> >>>>>> replaced by
> >>>>>> JS> linkingCirlce-f.svg (test case with explanatory text is
> >>>>>> visible).
> >>>>>>
> >>>>>> b) is correct. This is why the png reference image shows what
> >>>>>> it looks
> >>>>>> like when b) happens.
> >>>>>>
> >>>>>> An issue with testing this sort of functionality is that the
> >>>>>> tests are
> >>>>>> intended to be separate from the test harness. The tests can
> >>>>>> be run
> >>>>>> standalone (eg, loading the svg files one by one into a
> >>>>>> viewer), or
> >>>>>> using an svg harness, or using an html object harness, or an html
> >>>>>> embed harness. other custom harnesses (eg a script based one, a
> >>>>>> harness that shows an extra image for regression testing,
> >>>>>> whatever)
> >>>>>> are possible.
> >>>>>>
> >>>>>>
> >>>>>> This test could be made clearer, for the html object harness,
> >>>>>> at the
> >>>>>> expense of making it specific to that harness. we tried to
> >>>>>> avoid that.
> >>>>>> Can you suggest improved wording that would improve this case
> >>>>>> while
> >>>>>> also allowing for harnesses where the svg  was tested standalone?
> >>>>>>
> >>>>>
> >>>>> Chris,
> >>>>>
> >>>>> I can't really think of any wording that would clarify this -
> >>>>> because
> >>>>> I was thinking that part of this test can be used to ensure
> >>>>> that the
> >>>>> UAs can handle some sort of HTML + SVG integration
> >>>>> consistently.  With
> >>>>> the full HTML test case harness, this is an example of CDR.  I
> >>>>> realize
> >>>>> that this would really be in a CDF test suite and not a SVG test
> >>>>> suite.
> >>>>>
> >>>>> Anyway, in the test at
> >>>>> http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/
> >>>>> full-linking-a-01-b.html:
> >>>>>
> >>>>> 1) Firefox 2 and 3a both change the HTML:object "frame" to be
> >>>>> that of
> >>>>> linkingCircle-f.svg and leave the test harness HTML alone.
> >>>>> 2) Opera 9.1 and Konqueror 3.5.5 both change the entire web
> >>>>> page to be
> >>>>> that of linkingCircle-f.svg, wiping out the test harness HTML
> >>>>> page.
> >>>>>
> >>>>> Do all 4 user agents mentioned above pass this test case when
> >>>>> it comes
> >>>>> to SVG?  If I use it to test CDF, which one is at fault?
> >>>>>
> >>>>> For practical use of SVG with HTML on the web today, I'd like
> >>>>> to be
> >>>>> able to tell one browser A that they need to get in sync with
> >>>>> browser
> >>>>> B.  In this case, I believe the correct behavior is exhibited by
> >>>>> Mozilla and that Opera/Konqueror are at fault (because there
> >>>>> was no
> >>>>> target="_top" on the link).  But actually I'm still not 100%
> >>>>> confident
> >>>>> in that because I'm not sure that the HTML object is really a
> >>>>> "frame"
> >>>>> in the parlance of HTML links...
> >>>>>
> >>>>> Thanks,
> >>>>> Jeff
> >>>>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>>  Chris Lilley                    mailto:chris@w3.org
> >>>  Interaction Domain Leader
> >>>  Co-Chair, W3C SVG Working Group
> >>>  W3C Graphics Activity Lead
> >>>  Co-Chair, W3C Hypertext CG
> >>>
> >>>
> >
> >
> >
> >
> > --
> >  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 Monday, 2 April 2007 02:44:37 UTC