303400 - Feedview should hook into gecko next to XML prettyprint

Status: NEW

(Core :: XML, defect)

Description

[Axel Hecht]

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.

Comment 1

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

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.

Comment 2

[Axel Hecht]

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.

Comment 3

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

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.

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

> I.e. a document can't be both a feed and a docbook.

What about mixed-namespace documents, couldn't those cause some overlap?

Comment 5

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

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.

Comment 6

[Axel Hecht]

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

Comment 7

[Phil Ringnalda (:philor)]

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

Comment 8

[Phil Ringnalda (:philor)]

*** Bug 305087 has been marked as a duplicate of this bug. ***

Comment 9

[Phil Ringnalda (:philor)]

Moving to Core:XML in case you still want this for other uses: Son of Feedview is going in even earlier in bug 324985.