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/ Regards– –Doug 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: http://w3c.github.io/findtext/ "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 welcome. 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> @fjhirsch [1] http://www.w3.org/2014/06/webapps-charter.html#deliverables [2] http://www.w3.org/annotation/charter/#scope
