User-Agent: Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040212 Firebird/0.8.0+ As shown with the testcase of bug 182323, XPointer framework and element scheme and extensible element scheme registration work with text/xml files. But when we try with XHTML files with the application/xhtml+xml media type instead of text/xml, it doesn't work.. Reproducible: Always Steps to Reproduce: 1. Open a XHTML file with the application/xhtml+xml media type 2. Try to access an element with #element() Or 1. Test http://www.tomoakley.net/xml/xhtml.xhtml#element(definitions) 2. Compare with http://www.tomoakley.net/xml/xhtml.xhtml#definitions Actual Results: Nothing occures Expected Results: The same behaviour than with text/xml type (the page scrolls until the position of the element)
Confirmed. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
See http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsPresShell.cpp#3986 That probably needs to be hoisted up to nsIDocument (and just do nothing in HTML but not XHTML docs).
Hrm.. except this is scriptable... Should this move to a separate interface of its own and be implemented by XHTML documents too?
I'm not familiar enough with the code structure to know how easy or hard it is to do the right thing, but it's clear what the right thing is: XPointer is intended to work with any document format that is backed by XML. It should certainly work in xhtml documents, whether they are served as application/xml, text/xml, application/xhtml+xml, or even text/html, as described in http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801/ . Of course that means, for text/html, that you need to look at more than just the supplied content-type (because old soupy html can also be served with the same content type). Pointers should also work in any application/foo+xml type, and other documents that have their own registered content-types but are known to be xml. Again, I can't suggest the best way to make that happen, or how difficult it would be as the existing code is structured - but anything short of that would be an arbitrary limitation.
> It should certainly work in xhtml documents, whether they are served as > application/xml, text/xml, application/xhtml+xml, or even text/html I don't think that last is the case. A document served with that type is not treated as XHTML in any way; it's treated as HTML (which it is).
>> application/xml, text/xml, application/xhtml+xml, or even text/html > I don't think that last is the case. A document served with that type is not > treated as XHTML in any way; it's treated as HTML (which it is). I can see a few different things that might mean: 1. Stuff that comes under a text/html content type is never XHTML, and always only HTML. (A claim on fact, but not always true, because http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801/ allows text/html as one of the content types for serving an XHTML doc). 2. Stuff that comes under a text/html content type *should never be treated as* XHTML, but always only as HTML. (A claim on what *should* be done.) The media-types note could be read this way (after all, it says such documents "will not be processed as XML, e.g. well-formedness errors may not be detected by user agents). I read it more as a caution to authors than a prohibition to implementors, though: the point of choosing text/html is to make your content available to the widest audience of browsers, some of which won't process it as XML so you can't count on that. But a browser that does grok XML and can see that what it received under the text/html content type is XHTML does not seem forbidden to use that knowledge (though it may have to apply HTML rules for DOM, style sheets, and encodings). 3. Stuff that comes under a text/html content type *is not treated as XHTML in any way by our implementation as it stands* (a claim on existing implementation details). That may well be the case, and your sense is better than mine for how deep that limitation might run. Bringing that back to the question "what should be done with XPointer," I think it helps to ask "what is XPointer for?" A huge benefit of XPointer is an easy way to point at specific places in content served by others without depending on special effort on their part. It comes closest to fulfilling its promise when it works *in as many circumstances as it possibly can* - that is, wherever the underlying content can be treated as XML. Authors could moot this point for XHTML by always using content negotiation to call their stuff application/xhtml+xml for browsers that understand it, and only calling it text/html for browsers that don't, as in http://www.w3.org/2003/01/xhtml-mimetype/content-negotiation. But that's another example of special author effort, and another example where it's a bigger win if the author can neglect to do that and it doesn't stop other people from writing pointers that work anyway.
> Stuff that comes under a text/html content type *should never be > treated as* XHTML, but always only as HTML. This is correct. As long as the data follows Appendix C of the XHTML specification, this will mostly work, but DOM compatibility is pretty broken between XHTML-as-XHTML and XHTML-as-HTML in all sorts of way (much more serious than whether xpointer works; consider the child nodes of <table> issue). > that is, wherever the underlying content can be treated as XML. A data stream that has been parsed with the tag-soup parser like any other tag-soup is tag-soup. Nothing to do with XML. Note that the vast majority of "xhtml" documents out there (which are served as text/html) aren't even well-formed XML.... so treating them as XML is a non-starter.
This looks like wontfix; we dropped xpointer entirely a few years ago.