Hi, Eliott–

Good question.

I don't have a great answer yet, but this is something that will need to be worked out with Shadow DOM, not just for this spec, but for Selection API and others, as well as to CSS, which has some Range-like styling.

I don't know if this means a change to Shadow DOM, to Range, or to FindText and other specs.

If there were a better way of representing non-element document segments than ranges, one that's more friendly to Shadow DOM, I'd be open to that as a return / representation type. I just don't know what that would be; if someone has a suggestion, please let me know.

In the meantime, could you raise that as an issue [1]? Or I can do it by proxy.

[1] https://github.com/w3c/findtext/


On 10/6/15 4:49 PM, Elliott Sprehn wrote:
How does this work with shadow dom? Range is not very friendly to that.

On Oct 6, 2015 4:35 PM, "Frederick Hirsch" <w...@fjhirsch.com
<mailto:w...@fjhirsch.com>> wrote:

    This is a call for consensus (CfC) to publish a First Public Working
    Draft (FPWD) of FindText API; deadline 14 October (1 week)

    This FindText API is joint deliverable of the WebApps WG and Web
    Annotation WG (listed as "Robust Anchoring" in the charters [1], [2]).

    This is a Call for Consensus (CfC) to publish a FPWD of the FindText
    API, using the following Editor's Draft as the basis:


    "This specification describes an API for finding ranges of text in a
    document or part of a document, using a variety of selection criteria."

    This API was presented to the WebApps WG last TPAC under a different
    name, and with a fairly different design; it was modified to fit the
    feedback from that meeting and from others, including narrowing of
    scope, the introduction of Promises, and exposing low-level
    functionality in the spirit of the Extensible Web.

    The specification is largely based on the Annotator JavaScript
    library's "robust anchoring" code, and a standalone polyfill is
    under development. Feedback from possible implementers is especially

    This CfC satisfies the group's requirement to "record the groups'
    decision to request advancement".

    By publishing this FPWD, the group sends a signal to the community
    to begin reviewing the document. The FPWD reflects where the groups
    are on this spec at the time of publication; it does _not_
    necessarily mean there is consensus on the spec's contents and the
    specification may be updated.

    If you have any comments or concerns about this CfC, please reply to
    this e-mail by 14 October at the latest. Positive response is
    preferred and encouraged, even a +1 will do  Silence will be
    considered as agreement with the proposal.

    regards, Frederick & Rob

    Frederick Hirsch, Rob Sanderson

    Co-Chairs, W3C Web Annotation WG

    www.fjhirsch.com <http://www.fjhirsch.com>

    [1] http://www.w3.org/2014/06/webapps-charter.html#deliverables

    [2] http://www.w3.org/annotation/charter/#scope

Reply via email to