- From: Chris Lilley <chris@w3.org>
- Date: Thu, 29 Mar 2007 23:31:07 +0200
- To: "Jeff Schiller" <codedread@gmail.com>
- Cc: public-cdf@w3.org, www-svg@w3.org, sjoerd@w3future.com, bzbarsky@mit.edu, <roc@ocallahan.org>
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
Received on Thursday, 29 March 2007 21:31:26 UTC