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..
Steps to Reproduce:
1. Open a XHTML file with the application/xhtml+xml media type
2. Try to access an element with #element()
1. Test http://www.tomoakley.net/xml/xhtml.xhtml#element(definitions)
2. Compare with http://www.tomoakley.net/xml/xhtml.xhtml#definitions
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
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
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
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
allows text/html as one of the content types for serving an XHTML
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
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
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.