Hi, Chris- Chris Lilley wrote: | | DS> Problem 2: There is no specified behavior for how | fragment IDs are | DS> to be treated in SVG. There are many options (it might | translate the | DS> view so that the element is in the top left of the screen, or the | DS> exact center of the screen, or just enough so that it is | visible, or | DS> it might even change the viewBox so that the element fills up the | DS> screen). | | Right. It just has to make the linked-to object visible.
Just to clarify, by "linked-to object" you mean the element bearing the specified id element and not just the whole document, right? Because from my reading of "17.2.2 SVG fragment identifiers", there is no requirement to make the id-element (the fragment identifier) visible. It says: "If the SVG fragment identifier addresses any element other than a 'view' element, then the document defined by the closest ancestor 'svg' element is displayed in the viewport using the view specification attributes on that 'svg' element." So, if you have a link to 'myfile.svg#myId', if the nearest 'svg' element to 'myId' is the root, and 'myId' is a rect at, say, y='1000' and is outside the viewport/viewBox, it won't be visible. Personally, I think that the SVG Spec should specify that 'myfile.svg#myId' is assumed to be an implicit view that includes the id-element. Much more intuitive, and the outlier cases are miniscule. When *wouldn't* you want such behavior? Of course, if the element doesn't have a rendered bbox (say, in the case of display='none'), it shouldn't attempt change the viewport. | DS> All of these behaviors are specified for the 'SVG view | DS> specification' [2], using syntax like | DS> MyDrawing.svg#svgView(viewBox(0,200,1000,1000)), but as far as I | DS> know, no viewer has yet imlemented that. | | Its implemented by Batik and by CSIRO. | | (Of course, it could have been implemented by ASV and Corel | too, in theory, but we wouldn't know because of the browser | those are hosted in). | | DS> This is a real pity, because that rocks. Man... No, instead, all | DS> viewers I know about simply ignore the fragment-id. | | Yes, it is. (I would have thought you would be familiar with Batik) Oh, yeah... I think I heard about that... "Batik," you say? I'll have to write that one down... ;) I've got to confess, I didn't check Batik, because I concentrate mostly on common Web browsers for tasks like this. I meant that it's unimplemented in ASV, Firefox, and Opera. Thanks for setting me straight. It does work, as you say, in Batik, but there's a bit of odd behavior... in the location bar, the fragment identifier is doubled. For instance, svg2.svg#svgView(viewBox(200,200,100,100)) becomes: svg2.svg#svgView(viewBox(200,200,100,100))#svgView(viewBox(200,200,100,100)) No big deal, but I guess I'll file a bug report. BTW, seeing this in action, it really does rock, as predicted. Regards- Doug [EMAIL PROTECTED] www.vectoreal.com ...for scalable solutions. ------------------------ Yahoo! Groups Sponsor --------------------~--> 1.2 million kids a year are victims of human trafficking. Stop slavery. http://us.click.yahoo.com/.QUssC/izNLAA/TtwFAA/1U_rlB/TM --------------------------------------------------------------------~-> ----- To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" ---- Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
