We implemented it, but authors don't write it. See URL for more information.
I guess this depends on bug 32832 getting fixed ;)
(In reply to comment #0)
> We implemented it, but authors don't write it. See URL for more information.
It'd be nice to have some more information though, any codesize numbers? It doesn't look very big to me. Not arguing against this removal but it's not the slam dunk that webservices was imho.
Regarding authors, I think this would be useful for extension developers if they had an easy way to generate XPointers from DOM ranges. Hopefully an extension based on http://xpointerlib.mozdev.org/ (integrated with the code from bug 319768) together with extension dependencies will make this possible in the future.
(In reply to comment #1)
> I guess this depends on bug 32832 getting fixed ;)
Not really, that's a bug for the xpointer() scheme. We do have the XPointer framework and a couple of other schemes (iirc element, xmlns, xpath) in the tree. This bug should probably be about dropping XML pointer support, which would be the XPointer framework and the schemes we implemented and the FixPtr support.
(In reply to comment #2)
> (In reply to comment #0)
> > We implemented it, but authors don't write it. See URL for more information.
> It'd be nice to have some more information though, any codesize numbers? It
> doesn't look very big to me. Not arguing against this removal but it's not the
> slam dunk that webservices was imho.
Definitely not going to have the huge codesize win, but it will remove code from nsDocument, nsXMLDocument, and nsPresShell.
It would love to use XPointer URL fragments in XHTML (Bug 159716) and HTML documents and to see cool things in the browser like Bug 159716. I think this could be a differentiator for Firefox if it was usable on the existing web today... Imagine: here's a link that goes to the first occurence of "foobar" on the web page...
Sorry, that first Bug reference should be to Bug 235409 ("XPointer element scheme doesn't work with XHTML media type")
Can I cast negative votes? I really think it would be shortsighted to drop
this support. "We implemented it, but authors don't write it" seems to miss
the point that XPointer, if implemented and usable, is something that
anybody can use, even just in sending a URL to Mom, to point into the
relevant part of a document even when the author took no special steps
to facilitate that. And low utilization so far can also reflect that
its support in FF and SeaMonkey hasn't been very well publicized, there
haven't been examples (other than testcase attachments on bugzilla
reports) offered to show what you can do with XPointer and how easy
it is, and (this is big) it doesn't work yet in the very most common
content types that people would send links to Mom into (Bug 235409).
That makes it seem pretty premature to talk about DROPPING the support.
(In reply to comment #6)
> Can I cast negative votes?
There's no voting. We welcome comments that provide new information, but we don't welcome voting and dogpiling. It's too easy to game for niche features.
So, please restrict comments to those which add new information.
Note bug 159716, which was mentioned above. It doesn't have to be xpointer for that use case, and it can't be until we support xpointer on HTML, but it'd be really nice to have something that fills that need that Places or extensions could build on... I've wished for something like that several times recently, and it's come up in a few contexts for others.
OK, so it looks like we never actually moved the xpointer impl into mercurial. We've now shipped 1.9.1, 1.9.2, and about to ship 2.0 with no xpointer support. I think we can consider this fixed. ;)
Bug 457102 covers the dead-code removal.