« XO & XP | Main | *OA Overload »

Sunday, May 18, 2008


Feed You can follow this conversation by subscribing to the comment feed for this post.

Michael(tm) Smith

Hi Erik, This seems worth directly discussing with those participating in work on the HTML5 draft. I encourage you to join the HTML WG and start a discussion about on the public-html mailing list, or/and to post a message about it to the whatwg discussion list. --Mike

Ian Hickson

To echo Mike's comments, please don't hesitate to bring this kind of thing up on the mailing lists (either the WHATWG one or the HTMLWG -- see http://whatwg.org/mailing-list for details on joining the WHATWG list, the HTMLWG list is a bit harder to join).

The biggest problem I can see is reliability. I don't really see any way to make XPointer-like solutions resilient enough to work on the Web. That, and backwards-compatibility issues, are really the only things blocking progress here.


mike & ian: thanks for your comments! i am currently in the process of joining the HTMLWG list, but currently the systems seems to be thoroughly confused by the fact that a while ago i already was a member of another WG. but i hope to get access soon and will then raise this issue on the list.

of course there are resilience issues, but i think the utility of being able to point to arbitrary fragments on an HTML page would offset the risk of these identifiers breaking when the page changes. the spec could actively try to minimize breakage by encouraging page authors to use ids for important structural parts, and by defining how browsers should construct fragments. anyway, we'll see what others think about that...

Jeff Schiller

Hi Erik,

I caught your post on the public-html mailing list and wanted to let you know about my Firefox extension that does what you're trying to do with existing HTML web pages today using XPointer. There is also a user.js for Opera that supports this.

This is just in case you feel like playing with it.

Jeff Schiller

Larry Masinter


makes the case that robust pointers need more than fragment identifiers.

larry, thanks for the link! and i certainly did not want to imply that my (premature and quick and dirty) initial proposal for better fragment identifiers produces robust fragment identifiers. that would be a much more challenging task. all i wanted to propose was that html should mature to a point where fragment identifiers can identify things beyond the current @id-only definition for them.

the article states that "the web develops as an increasingly sophisticated hypertext platform", and i think that (sadly) this not really true. at best, it becomes a platform for hypertext islands (at least for those web sites which actually care to produce hypertext), but more and more authors go down the "why link when people can search" route, instead of choosing the "if you link, people don't have to search" route. and maybe putting google in charge of html5 is not really the best way to try to improve html as a hypertext format. what happens is that it is being mostly improved as a publishing platform for interactive documents and services - which is fine. but i think the h in html still should be taken seriously.

anyway, there are many ways in which fragment identifiers could be improved for html5 (in html4, they basically are as bad as it can get), and i think the important first step is to understand that html5 hopefully should not just incorporate the most popular things people have solved with scripting over the past years. it should also seize the opportunity to improve the web as a hypermedia platform. after all, that is why it's called the web.

Harrison Ainsworth

This has another value. It is arguably a better avenue than RDFa for bridging the GGG to the WWW, ie. RDF to the web.

RDFa is antithetical to RDF's essentially 'addititve', always open, graph engineering principle -- to make a predicate you must change the subject. But a good fragment scheme would allow RDF URIs to reference the web more effectively, enabling statements/triples to be added freely and separately.

On robustness, there is a natural temptation to ponder it, but think of basic URLs: they have none, yet the web has succeeded greatly. Totally disregarding robustness would be well founded, even well advised. Not trying too hard makes the web work.

I lean toward just child sequences. It lacks precision in the face of Proustian paragraphs, but would be mostly sufficient. And it grasps a range, which seems essential to the concept.

commenting system

Well, no doubt - HTML 5 is a real new and promising thing. It really shows some advantages over flash and java in some ways - hope that it will get its place in web 2.0 and web 3.0 soon.

The comments to this entry are closed.