Re: SVG Linking Test Case Questions

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 00:32:50 UTC