Re: Rough Draft of Robust Anchoring: the RangeFinder API

Hey Doug,

(Caveat 1: I am currently on the plane, queueing this comment; I am not sure when I will be online again, ie, when it will be mailed...)
(Caveat 2: this type of Interface design is not really my technical area, so apologies if what I say is fundamentally incorrect:-)

Some questions came to my mind while reading this.

- the querySelector is defined as an xpath selector. Shouldn't we define a similar mechanism for CSS selectors? (Note that the charter lists the CSS selector document as our input, too[1]).

- a similar question for SVG. The annotation model has an SVG "area selector", shouldn't that be reflected in this document? And you know SVG way better than I do, I am sure that there is a possibility for other types of selectors for SVG. Again another use case is selectors in media like video

(- In general, the various selector specifications, ie, in this document and in the annotation model should probably be reconciled, also in term of their textual definitions.)

- Maybe an answer to the previous questions is related to a more general question: I do not understand in the WebIDL spec how you provide 'extension points', ie, that users could plug in their own selection/search methods. I think we all agree that providing such extension points is important

- I do not have a clear model in my mind how the the interface works in terms of asynchronity/promises. Shouldn't the search method also return a Promise? What runs asynchronously and which are just synchronous calls? (Probably an example in Javascript could help.)

- The digital publishing world may have a separate use case: if I make a search for a text, which itself is presented in a paginated way, I would like to know on which *page* the result is. At this moment the information about pagination is difficult to get to, and the solutions are highly implementation dependent. However, the CSS WG has just started the so-called Houdini project that, if my understanding is correct, should provide a scripting interface to the information related to CSS structures (including paging). I just wonder how these mechanisms could be combined with RangeFinder. (Note that the Houdini project is at its infancy, and our answer may very well be that, in the first phase, we concentrate on DOM-related information only, leaving the CSS stuff for later. But it is worth some thought nevertheless...)

Before I forget, b.t.w.: thanks for writing this down!




> On 25 Feb 2015, at 24:48 , Doug Schepers <> wrote:
> Hi, folks–
> Just a quick note. Rob asked me to move this file, to keep the deliverables organized. It's now located at:
> Even this is a temporary location, though... I'll be moving it to soon, and adding the annotation capability to it.
> Feel free to review, but be aware that the URL is transitory.
> Regards–
> –Doug
> On 2/24/15 1:33 PM, Doug Schepers wrote:
>> Hi, folks–
>> After talking about Robust Anchoring with many people over the course of
>> the last couple years (!), with encouragement and good criticisms, I've
>> refined my notion of what's needed for a client-side API for Robust
>> Anchoring.
>> I've drawn up a strawman of my current thinking for an API called
>> RangeFinder [1].
>> It's very rough in places, but I'd appreciate any feedback on the spec
>> as it stands. I'd greatly appreciate any thoughts or opinions on it at
>> this stage.
>> I'm not sure it's mature enough for this yet, but at some point, I'd
>> like to engage the research and academic communities and the experts
>> who've published on text search algorithms, to polish this up and make
>> it not quite as embarrassing as it is currently. If anyone knows who we
>> should contact in that regard, please chime in. This is a great
>> opportunity to leverage all that research in the service of Web
>> developers and browsers!
>> [1]
>> Regards–
>> –Doug

Ivan Herman, W3C
Digital Publishing Activity Lead
mobile: +31-641044153

Received on Wednesday, 25 February 2015 17:50:07 UTC