This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Built-in Datatypes and Their Definitions The Built-in Datatype Hierarchy diagram printed very badly using Firefox 1.5.0.1. It also has unexpected dynamic behavior, When I click on one of the datatypes, I see a sub-window with a scroll bar showing me the entire document again, positioned on the datatype that I chose. This comment has been entered on behalf of the XML Query and XSL WGs.
(In reply to comment #0) > The Built-in Datatype Hierarchy diagram printed very badly using Firefox > 1.5.0.1. It also has unexpected dynamic behavior, When I click on one of the > datatypes, I see a sub-window with a scroll bar showing me the entire document > again, positioned on the datatype that I chose. I get essentially the same behavior with Firefox 1.5.0.7 . The subwindow seems to replace the figure. I notice that when I hover, Firefox says the link is to xxx#yyy, where xxx is the URL of the document and yyy is the local label for the specific datatype selected. OTOH, Apple's Safari behaves properly and says the link is to #yyy . FWIW. May be a bug in Firefox. :-(
I am able to reproduce the unexpected dynamic behavior with Firefox 3.0.5, although not with Opera 9.02 or Safari 3.2.1. It may be a bug in Firefox. There may be a way of avoiding it, and if so we will use that way. But at the moment I don't know how to work around the issue. Work continues on this issue.
Further investigation shows that there was indeed a related bug in Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=300868), which has now been fixed. What remains may be an irritating or confusing difference among browsers in the handling of SVG, but not a bug. When external SVG images are embedded using the 'object' element, Firefox treats the display of the SVG as constituting a separate frame. Traversal of hyperlinks within such a frame follows the usual rules for frames: the target of the link is displayed within that frame, without affecting the display or content of other frames, unless the hyperlink has a 'target' attribute. Adding 'target="_parent"' to the links within the SVG image causes the target of the hyperlink to be displayed not within the frame containing the SVG image, but within its parent (the one containing the display of the XSD spec), which yields the expected behavior. The addition of target="_parent" appears to have no effect on other browsers tested (Opera, Safari, IE) when they are displaying the XSD spec in their main window. I assume that if they are displaying the XSD spec in a frame (e.g. with commentary in another frame), then this addition will wreak havoc on the frameset. But I have not verified this assumption; even if it's true, the tradeoff between making normal display work in Firefox on the one hand, and causing minor problems for eventual future framed displays on the other, is a clear one. The change has been made both in the new SVG diagram drawn to resolve bug 2687 and in the old one (now deleted), in the copies of the spec at http://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.html (member-only link) etc. Andrew, if you would verify that the bug has been fixed, and report the fact to the XML Query and XSL WGs, we would be grateful. Close the issue to signal that you and they are satisfied by the resolution of the issue, and reopen it otherwise. If we don't hear from you in the next two weeks, we'll assume you and they are satisfied. Thank you.
I appreciate your effort in resolving this issue. With Firefox 3.0.5 I find that: - the figure displays correctly - the links work correctly - the figure appears correctly in print preview - the figure is blank when actually printed (which I do very little of these days) With Firefox 2.0.0.20 I find that - the text is missing from figure when displayed - the links work correctly - the figure overlays all pages in print preview I personally believe that 2.0.0.20 is old enough that you shouldn't spend additional effort on it.