- From: Dave Raggett <dsr@w3.org>
- Date: Wed, 4 Apr 2007 12:10:45 +0100 (BST)
- To: Olivier GENDRIN <olivier.gendrin@gmail.com>
- cc: public-html@w3.org
Note that quotes could overlap one another and cut across the document structure. This can be handled via separate references to the start and end of the quote and is essentially the same as a DOM Range. If the referenced document doesn't have anchors in the appropriate places, we need a way of describing where the anchors are in the referenced document. A candidate for this is XPointer, which while it was developed with XML in mind could also be applied to tag soup given the unambiguous DOM tree obtained using Hixie's proposed parsing rules. This may seem a bit of a stretch for some people, but there is already an implementation of XPointer for Mozilla, see http://xpointerlib.mozdev.org/ "XPointerLib allows you to create and resolve XPointers in W3C DOM Documents. Creation is implemented more fully than resolution. For any valid DOM Range or Mozilla Selection object, a function in the XPointerLib will create an equivalent XPointer." Another possibility is to use a server-side service for resolving the link and turning it into some thing appropriate for display by the browser, for instance, using Ajax invoked by a web page script. The XPointer fragment identifier syntax is backwards compatible in that existing browsers will just display the document for the URI ignoring the fragment identifier. This would provide a reasonable fall back if the user has disabled scripting. The great thing about this is that it doesn't require any changes to HTML, and could be applied to HTML4. Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett On Wed, 4 Apr 2007, Olivier GENDRIN wrote: > > (whoops, missed the list. I have to get used to the gmail interface) > > On 4/2/07, Gregory J. Rosmaita <oedipus@hicom.net> wrote: >> A) Quotes will need to be nested within one >> another, for often one quotes a source which, in >> turn, quotes a third party; is redefining the Q >> element as neither an inline nor block element, >> but as a "flow" element, equal to this task? > > Same mechanism than <ins>, <del> : > http://www.w3.org/TR/1999/REC-html401-19991224/struct/text.html#h-9.4. > > We could extent it to the <div>/<span> question. > > >
Received on Wednesday, 4 April 2007 11:11:18 UTC