Support TextPositionSelector (in the dom package) #75
Comments
As long as we stick to
We should be fine, at least for text nodes. The CSS white space properties make it important that parsers preserve the text nodes as is. I think the spec is still somewhat vague and open to interpretation. I am partial to using Iterating over a string in JavaScript yields strings representing the code points (each iteration may yield a string with more than one code units). As a result, one can also do However, I think we should consider going a step further and writing a text selector that consumes an iterator that yields chunks rather than receiving a full text with the initial call. This interface would be useful for streaming scenarios where the whole text may not be available or may be extremely large. The chunks themselves could be arrays or strings, and if we decide that they are strings we may wish to iterate over their code points. |
|
I started implementing this in the |
|
Implemented in #98. |
Following its specification.
Altough it looks simple, there may be challenges in ensuring we count characters correctly. From the spec (in the TextQuoteSelector section, but that is then referred to by the TextPositionSelector section):
The referenced ‘charmod’ (Character Model for the WWW) has a section on string indexing that may be relevant.
What still confuses me a little is what constitutes the exact text of a DOM. Given that normalisation should (why not must?) remove html tags, I suppose this assumes we deal with the source html.
What then to do with comments: are those text, or are their
<!--and-->parts to be removed? In the latter case, would the document’s total text equal the textContent of all children of the Document? (one may thinkdocument.documentElement.textContent, but that excludes whitespace and comments outside the<html>element)Possibly more problematic, can one even access the source html accurately enough through the DOM? Might a source parser have modified whitespace, thus leading to miscounts? I am not even talking about executed scripts that may modify the DOM too, I suppose we have to disregard that scenario.
Of course there are implementations already whose approach and behaviour we could copy, but it may be good to do the exercise of implementing based on the spec to ensure that it matches up, also to help detect discrepancies between implementations and spots where the spec may need to be improved/updated.
Any differences in implementations would likely result in misanchored annotations, so doing this imprecisely seems of little value; unless the use is explicitly limited to only apply to e.g. selector refinement within text nodes, which could be a strategy to take.
@tilgovi (or others): what are your thoughts about this, and about the implementation as it is done in dom-anchor-text-position, in Hypothesis, or elsewhere?
The text was updated successfully, but these errors were encountered: