If you load http://svn.sinz.com/browser-tests/test2.html you will notice that the top-right frame does not render as expected. However, this only happens with XML/XSLT generated pages and not HTML generated ones as can be seen in http://svn.sinz.com/browser-tests/test1.html. Also, if you load the frame URL (http://svn.sinz.com/browser-tests/test2/index.xml) into its own browser window/tab it renders almost exactly as the reference frame (http://svn.sinz.com/browser-tests/test2/ref.xml) does. You can use the "Open frame in new tab(or window)" option in Safari to see this. All of this code is available in read-only SVN access at http://svn.sinz.com/svn/Insurrection/trunk/browser-tests/ (You can safely do a "svn co http://svn.sinz.com/svn/Insurrection/trunk/browser-tests/" as it is not very large and includes all of the test code. (Note that most of the images are not in that part of the repository - I just noticed that some of the pages depend on some shared images with the main project. I may fix this if I get some time) While I only have 10.3.9 (since my iMac is too old to get 10.4) I have checked the behavior on 10.4 systems and they seem to have the exact same behavior. This may be related to bug #4054 where the XML/XSLT base URL is somehow confused. But the exact behavior does not make this a foregone conclusion.
Created attachment 4492 [details] xsltproc output This is the output that xsltproc creates from the test's index.xml and index.xsl, and Safari displays it exactly like it displays the test case itself. That is, it differs from the supplied reference rendering only in font size and margins. Could the reference rendering be wrong in this regard? Tested with 10.4.2 and its stock Safari/WebKit.
Well, after looking at the attachment the only difference (of substance) between it and the reference page is that the reference page has a <!doctype...> in it. So, I looked at the XSLT file and noticed that it does not specify a specific doctype, just a generic "HTML" type. So, while IE and Mozilla both assume some <!doctype...> for bare HTML, it seems that Safari assumes a different <!doctype...> for bare HTML and thus the rendering differences. I have updated the tests to include a specific doctype in the XSLT and it should now (with ToT) render correctly. (I can't verify that right now, so I am leaving this open for someone else to verify or for me to verify when I get the chance.)
I don't think this is a bug. The doctype determines your mode (quirks vs. strict). If you don't write out a doctype in the HTML you output (but did have one in your reference rendering), then it is logical you would see rendering differences because of the different modes. It may be that Firefox assumes strict mode because the original file was XML, but I don't think that is the correct behavior.
This probably has to do with the fact that Firefox doesn't "reparse" the HTML, so it probably just stays in strict mode. This of course causes Firefox to have all sorts of problems, since the HTML doesn't render as it would if it got parsed for the first time (e.g., document.write doesn't work). Our goal with our design is that the HTML you output should render exactly as it would if you had loaded that file directly (and not as the result of an XSL transform).
But it _is_ the result of an XSLT transform.
Sure, but that HTML result can have a doctype, and so it seems more appropriate for mode determination to be made based off the HTML. This allows someone to control the mode of the output. One could imagine wanting quirks mode HTML spit out by an XSL transform. Locking to strict seems wrong here, since the only way you'd have to get back to quirks mode would be with some crazy old doctype.
I was not saying that there still is a bug here. I was pointing out that I found an error in the test page due to the lack of the specifically set doctype. I have fixed that in the test pages now. The XSLT generated page should now have exactly the same doctype as the plain page. If the reference and the test pages (bottom and top frames in the test) now render the same then the doctype error in the XSLT was the reason for the last bit of rendering difference between the two in Safari.
Assigning bugs which hyatt is not actively working on to "nobody" for clarity/consistancy.
Created attachment 5398 [details] ToT rendering There is still a slight difference - text "Test #2" is positioned differently in "test" and "reference" frames. Or, rather, the image box at the left is higher.
I think we would have to get michael to comment again. I'm not sure if there is still a bug in Safari or the test case. The previous xslt bugs which came from michael were pretty much all catastrophic failures of our XSLT code... this one seems to work. But perhaps the text alignment difference you point out is a bug still.
As far as I can tell, the test, as it stands today, is correct. The top and bottom frames should render exactly the same (same box layout, same typeface, same sizes) I do not currently have a way to test this with ToT due to my Mac being too out of date to run 10.4. However, as far as I can tell, the XSLT should produce the "same" (modulo some non-significant differences) HTML as the reference frame HTML. (XLST processors I have here produce syntactically equal output) I don't know what the minor text rendering difference could be. I will attach the rendering as I see in on one of my test platforms. (Of the systems that render the XSLT at all, all but Safari render the two frames equally)
Created attachment 5405 [details] Rendering as seen from Mozilla based browsers Just for reference, this is the style of rendering I see in most of the browsers that handle XSLT. (Actually, all but Safari at this point, and Safari is very, very close)
The linked test now renders exactly like the reference for me with ToT. Don't know what fixed it, so closing as WORKSFORME.