Feedview currently observes each window load, and for unstyled XML, it kicks in after Gecko has done the XSLT transform for XML prettyprint. This is both a perf problem and a problem with the feed XSLT not working on the original DOM doc. I'm not confident the XML pretty printing result as good as we can for scripting. Exposing a general hook for unstyled XML would also enable the reuse of that approach for other XML formats, read docbook. See bug 194351, bug 109684. One suggestion is to use the observer service for this.
Some sort of observer sounds like a great idea. We would need to have some sort of priority mechanism since we want feedview to take priority over xml-prettyprint. We would also have to expose bit of information about the doc to the observer that the observer can use to choose wheather to apply its style or not. For example xml-prettyprint does not want to style documents that contain XHTML elements or stylesheets, whereas feedview doesn't care about either of those.
I was thinking of using the XML document as subject for the hook, and to use specific nsresults to indicate whether a observer wants to transform this doc. And if no observer yells, feed it to pretty printer. We could of course QI to a richer interface right away, which could return a priority number, for example.
Actually, i think you might be right that the normal observer interface is enough. We only really need 2 levels of priority; everything else and xml-prettyprint. Since stuff in the "everything else" group should never overlap. I.e. a document can't be both a feed and a docbook. So your suggestion should work fine.
> I.e. a document can't be both a feed and a docbook. What about mixed-namespace documents, couldn't those cause some overlap?
I don't think so. XSLT is able to copy parts of the document thorough, namespaces and all, then we'd normal layout rules to show that.
In terms of XSLT, yes, they could. For feedview, this is void, as they don't really nest XML, but encode HTML content. Docbook seems pretty self-contained, though a docbook stylesheet should probably have some guards to forward other namespaces, to make mathml work, for example. As soon as we support multiple XSLT stylesheets per processor, we could glue those together smoothely (with a default document stylesheet, that is).
> For feedview, this is void, as they don't really nest XML, but encode HTML > content. Be sure not to build that assumption into anything: Atom's content element can have any XML as children: <content type="application/foo+xml"><blah xmlns="...></blah></content> is perfectly valid Atom. You won't find docbook because of its namespace issues, but anything else, most certainly XHTML, you may.
*** Bug 305087 has been marked as a duplicate of this bug. ***
Moving to Core:XML in case you still want this for other uses: Son of Feedview is going in even earlier in bug 324985.