Bug 4358 – XSLT gets the wrong style sheet

• Component: XML
• Status: RESOLVED WORKSFORME

[Michael Sinz]

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.

[Alexey Proskuryakov]

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.

[Michael Sinz]

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.)

[Dave Hyatt]

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.

[Dave Hyatt]

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).

[Ian 'Hixie' Hickson]

But it _is_ the result of an XSLT transform.

[Dave Hyatt]

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.

[Michael Sinz]

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.

[Eric Seidel (no email)]

Assigning bugs which hyatt is not actively working on to "nobody" for clarity/consistancy.

[Alexey Proskuryakov]

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.

[Eric Seidel (no email)]

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.

[Michael Sinz]

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)

[Michael Sinz]

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)

[Alexey Proskuryakov]

The linked test now renders exactly like the reference for me with ToT. Don't know what fixed it, so closing as WORKSFORME.