688712 - xml stylesheet linking should treat specified media type as advisory

Status: RESOLVED WONTFIX

(Core :: XML, defect)

Description

[Julian Reschke]

It appears the code handling stylesheet links (be it by HTTP header field or by a link from the XML document) only works for XSLT when an XSLT media type was specified.

According to the spec (http://www.w3.org/TR/xml-stylesheet/#PA-type), the type however is advisory only, so both specifying the "wrong" type and no type at all should work, if the XSLT is served with the proper media type.

Test cases:

http://greenbytes.de/tech/tc/xslt/#pi-no-tx

and

http://greenbytes.de/tech/tc/xslt/#pi-tc-tx

(Note: all UAs seems to do this wrong)

Comment 1

[Simon Pieters [:zcorpan]]

The xml-stylesheet spec lacks requirements for UAs (intentionally).

http://dev.w3.org/csswg/cssom/#requirements-on-user-agents-implementing-the-xml-stylesheet-processing-instruction has requirements for CSS, but not really for XSLT (step 3 allows the UA to not fetch anything if type is not supported--it'd make sense to allow the same for XSLT). The XSLT spec might contain some requirements around xml-stylesheet, I don't know however if they're useful.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Julian, the only way to allow not specifying a type is to start the fetch and then once you know what sort of sheet it is to treat it as either XSLT or CSS.

Unfortunately, the processing model for CSS and XSLT stylesheets is very different, and in particular the list of things that you can do while loading the stylesheet and how you do them is very different.  The only safe way to do post-load dispatch is to restrict what you do to the intersection of things that are safe for the two, which is more or less empty.

In practice, that would mean that as soon as an xml-stylesheet PI with no type is hit the UA would have to immediately stop the XML parser (before any more PIs, or worse yet elements are parsed), do a fetch on the URL, examine the type, and then dispatch it to the right place and restart the parser.

This is a lot of complexity for an edge case, and furthermore gives a terrible user experience in terms of performance if as sheet with no type is used.  Similar for doing dispatch based on just the post-load type as opposed to just verifying that the post-load type matches the advisory type.

Given that, I would be very strongly tempted to wontfix this bug.

> (Note: all UAs seems to do this wrong)

In which case it may make more sense to align the spec to reality than to align UAs to something no one really wants to have in the first place.

Comment 3

[Julian Reschke]

I agree that this is an edge case; I opened the bug mainly for the purpose to have it tracked. I also agree that if nobody wants to treat it as advisory, then the spec probably needs an update.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Oh, we do treat it as advisory to some extent.  In standards mode, or for cross-site loads, if the actual server-provided type is not text/css while type="text/css" was on the PI we don't load the stylesheet.

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yeah, the processing model for CSS and XSLT is completely different, so for any sane implementation and user experience we need to make a decision about what processing model to use before we hot the server.

It was very unforunate that the sam PI was used to invoke both processing models, but alas that is too late to fix now.

Marking this WONTFIX. Would love to have specs that actually define processing model for the xml-stylesheet PI and which reflect reality. Browsers treat it wildly differently, especially with regards to XSLT handling.