Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

[Benjamin Young]

+1 Looks like I great start. Thanks again, Doug!
On Oct 8, 2015 11:51 AM, "Frederick Hirsch"  wrote:

> +1 to FPWD of FindText API
>
> > On Oct 7, 2015, at 11:38 AM, Robert Sanderson 
> wrote:
> >
> > +1 to FPWD
> >
> > On Wed, Oct 7, 2015 at 8:34 AM, Ivan Herman  wrote:
> > I am happy to have this documents published as FPWD.
> >
> > Ivan
> >
> >
> > > On 06 Oct 2015, at 22:32 , Frederick Hirsch  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
> > > @fjhirsch
> > >
> > > [1] http://www.w3.org/2014/06/webapps-charter.html#deliverables
> > >
> > > [2] http://www.w3.org/annotation/charter/#scope
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> > 
> > Ivan Herman, W3C
> > Digital Publishing Lead
> > Home: http://www.w3.org/People/Ivan/
> > mobile: +31-641044153
> > ORCID ID: http://orcid.org/-0003-0782-2704
> >
> >
> >
> >
> >
> >
> >
> > --
> > Rob Sanderson
> > Information Standards Advocate
> > Digital Library Systems and Services
> > Stanford, CA 94305
>
> regards, Frederick
>
> Frederick Hirsch
> Chair, W3C Device APIs WG (DAP)
>
> www.fjhirsch.com
> @fjhirsch
>
>
>
>
>

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

[Frederick Hirsch]

+1 to FPWD of FindText API

> On Oct 7, 2015, at 11:38 AM, Robert Sanderson  wrote:
> 
> +1 to FPWD
> 
> On Wed, Oct 7, 2015 at 8:34 AM, Ivan Herman  wrote:
> I am happy to have this documents published as FPWD.
> 
> Ivan
> 
> 
> > On 06 Oct 2015, at 22:32 , Frederick Hirsch  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
> > @fjhirsch
> >
> > [1] http://www.w3.org/2014/06/webapps-charter.html#deliverables
> >
> > [2] http://www.w3.org/annotation/charter/#scope
> >
> >
> >
> >
> >
> >
> 
> 
> 
> Ivan Herman, W3C
> Digital Publishing Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> ORCID ID: http://orcid.org/-0003-0782-2704
> 
> 
> 
> 
> 
> 
> 
> -- 
> Rob Sanderson
> Information Standards Advocate
> Digital Library Systems and Services
> Stanford, CA 94305

regards, Frederick

Frederick Hirsch
Chair, W3C Device APIs WG (DAP)

www.fjhirsch.com
@fjhirsch

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

[Ben De Meester]

+1 to FPWD

Greetings,
Ben

Ben De Meester
Researcher Semantic Web
Ghent University - iMinds - Multimedia Lab | Faculty of Engineering and
Architecture | Department of Electronics and Information Systems
Gaston Crommenlaan 8 bus 201, B-9050 Ledeberg-Ghent, Belgium
t: +32 9 331 49 59 | e: ben.demees...@ugent.be | URL:
http://users.ugent.be/~bjdmeest/

2015-10-07 21:13 GMT+02:00 Raphaël Troncy :

> Hi Doug,
>
> It's just one of the building blocks of a full set of robust anchoring
>> features, some of which might be standardized, but which may actually be
>> done in script. We'll most likely gather together those pieces in the
>> sort of umbrella document you suggest… maybe something like "Mapping Web
>> Annotation Data Model Selectors to Client-side APIs" (or something more
>> pithy.
>>
>
> Thanks for the clarification, this is exactly what I had in mind. I was
> afraid that the "Robust Anchoring" deliverable defined in the charter was
> reduced to the "FindText API" (which is, between, absolutely necessary and
> useful) and I'm happy to read that there will be other documents produced.
>
>
>   Raphaël
>
> --
> Raphaël Troncy
> EURECOM, Campus SophiaTech
> Multimedia Communications Department
> 450 route des Chappes, 06410 Biot, France.
> e-mail: raphael.tro...@eurecom.fr & raphael.tro...@gmail.com
> Tel: +33 (0)4 - 9300 8242
> Fax: +33 (0)4 - 9000 8200
> Web: http://www.eurecom.fr/~troncy/
>
>

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

[Raphaël Troncy]

Hi Doug,


It's just one of the building blocks of a full set of robust anchoring
features, some of which might be standardized, but which may actually be
done in script. We'll most likely gather together those pieces in the
sort of umbrella document you suggest… maybe something like "Mapping Web
Annotation Data Model Selectors to Client-side APIs" (or something more
pithy.


Thanks for the clarification, this is exactly what I had in mind. I was 
afraid that the "Robust Anchoring" deliverable defined in the charter 
was reduced to the "FindText API" (which is, between, absolutely 
necessary and useful) and I'm happy to read that there will be other 
documents produced.


  Raphaël

--
Raphaël Troncy
EURECOM, Campus SophiaTech
Multimedia Communications Department
450 route des Chappes, 06410 Biot, France.
e-mail: raphael.tro...@eurecom.fr & raphael.tro...@gmail.com
Tel: +33 (0)4 - 9300 8242
Fax: +33 (0)4 - 9000 8200
Web: http://www.eurecom.fr/~troncy/

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

[Doug Schepers]

Hi, Raphaël–

Yes, this is one narrowly-scoped piece of generalized functionality that 
we hope can get broad agreement and implementation.


It's just one of the building blocks of a full set of robust anchoring 
features, some of which might be standardized, but which may actually be 
done in script. We'll most likely gather together those pieces in the 
sort of umbrella document you suggest… maybe something like "Mapping Web 
Annotation Data Model Selectors to Client-side APIs" (or something more 
pithy.


Regards–
–Doug

On 10/7/15 11:56 AM, Raphaël Troncy 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]).


+1 for publishing this document as FPWD but one clarification request:
the original "Robust Anchoring" had a wide scope covering various types
of documents while the FindText API document focuses on textual
documents. Would there be another "umbrella document" produced by the
Working Group that would refer to various specifications to perform
robust anchoring on various type of documents, such as listing the
FindText API, the CSV fragment RFC 7111, the Media Fragments API, etc. ?
Best regards.

   Raphaël

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

[Raphaël Troncy]

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]).


+1 for publishing this document as FPWD but one clarification request: 
the original "Robust Anchoring" had a wide scope covering various types 
of documents while the FindText API document focuses on textual 
documents. Would there be another "umbrella document" produced by the 
Working Group that would refer to various specifications to perform 
robust anchoring on various type of documents, such as listing the 
FindText API, the CSV fragment RFC 7111, the Media Fragments API, etc. ?

Best regards.

  Raphaël

--
Raphaël Troncy
EURECOM, Campus SophiaTech
Multimedia Communications Department
450 route des Chappes, 06410 Biot, France.
e-mail: raphael.tro...@eurecom.fr & raphael.tro...@gmail.com
Tel: +33 (0)4 - 9300 8242
Fax: +33 (0)4 - 9000 8200
Web: http://www.eurecom.fr/~troncy/

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

[Robert Sanderson]

+1 to FPWD

On Wed, Oct 7, 2015 at 8:34 AM, Ivan Herman  wrote:

> I am happy to have this documents published as FPWD.
>
> Ivan
>
>
> > On 06 Oct 2015, at 22:32 , Frederick Hirsch  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
> > @fjhirsch
> >
> > [1] http://www.w3.org/2014/06/webapps-charter.html#deliverables
> >
> > [2] http://www.w3.org/annotation/charter/#scope
> >
> >
> >
> >
> >
> >
>
>
> 
> Ivan Herman, W3C
> Digital Publishing Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> ORCID ID: http://orcid.org/-0003-0782-2704
>
>
>
>
>


-- 
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

[Ivan Herman]

I am happy to have this documents published as FPWD.

Ivan


> On 06 Oct 2015, at 22:32 , Frederick Hirsch  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
> @fjhirsch
> 
> [1] http://www.w3.org/2014/06/webapps-charter.html#deliverables
> 
> [2] http://www.w3.org/annotation/charter/#scope
> 
> 
> 
> 
> 
> 



Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/-0003-0782-2704






signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

[Doug Schepers]

Hi, Yosi–

On 10/6/15 9:30 PM, Yoshifumi Inoue wrote:

It's exciting!


Thanks!



For Shadow DOM, current Blink implementation traverses composed tree
rather than DOM tree. We introduced a concept position in composed
tree and ephemeral range in composed tree; "ephemeral" means range in
composed tree isn't live. Ephemeral range objects aren't update at
DOM mutation.

A continuation position, e.g. highlight find result, is specified by
composed tree position but implemented in collapsed range, since
positions in composed tree can be represented by DOM node position.


Makes sense.



From implementation, FindText.cursor is very expensive, UA needs to
serialize DOM nodes to plain text to get DOM node and offset. Note:
Blink has an implementation for this called PlainTextRange for IME
API.

I would like to proposed FindText API to be defined top on Text
Iteration API or Plain Text Serialization API, both of them aren't
specified yet, instead of Node.textContent. These API can define
HTMLElement.innerText, not standard but most of UA have it and
causes interoperability issue, and plain text format of clipboard.


Sure, I definitely want to do this in the most efficient way possible.

I'm happy to help define a Text Iteration API or Plain Text 
Serialization API; I'm no expert in that, but I can help with the 
editing work. Do you have any more information about those?




Just FYI: Here is a presentation from Yandex presented on last November
on Blink On conference:
*
https://docs.google.com/presentation/d/18UHSNEqkFW2toj7Qfo5CcuTuQsFLOibbAMq2VSWoE4I/edit?usp=sharing
*
https://docs.google.com/document/d/1HlPDpwXzzuKp0n5qkKaIL9mYkjtlQHD37OF5pHQuXtE/edit?usp=sharing


Cool, thanks for sharing that! Looks like Konstantin and Andrey from 
Yandex would be good people to get in on this discussion. I'll point 
them to this thread.


Regards–
–Doug



2015年10月7日(水) 7:55 Doug Schepers mailto:schep...@w3.org>>:

Hi, Tab–

Thanks for the correction. I assumed that Houdini would expose more of
the underpinnings of the ::selection pseudo-element [1] and its ilk.
Maybe that hasn't surfaced (and maybe it won't). It does seem to be more
magic, though, which I'd thought we were trying to demystify.

But if there's no good story in Shadow DOM for things that explicitly
deal with Range, I think that needs a solution.


FWIW, JavaScript source-maps can comfortably deal with a similar
problem, with minified/cached versions of multiple source documents
(though I guess not multiple instantiations of the same source
document). Still, I'd expect there's a non-terrible solution for
serializing and expanding Shadow DOMs and pinpointing specific
instantiations.

(This makes me wonder how Shadow DOM is dealing with accessibility APIs;
I'm assuming there's a good story there, and maybe something we can draw
upon.)

[1] https://drafts.csswg.org/css-pseudo-4/#highlight-selectors

Regards–
–Doug

On 10/6/15 6:38 PM, Tab Atkins Jr. wrote:
 > On Tue, Oct 6, 2015 at 3:34 PM, Doug Schepers mailto:schep...@w3.org>> wrote:
 >> 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.
 >
 > CSS doesn't care about this, because it doesn't expose its selections
 > to the wider DOM; it can freely style whatever it wants, including
 > ranges that span into shadows.
 >
 > This is indeed equivalent to the problem that the generic Selection
 > API has with Shadow DOM, tho.
 >
 > ~TJ
 >

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

[Yoshifumi Inoue]

It's exciting!

For Shadow DOM, current Blink implementation traverses composed tree rather
than DOM tree.
We introduced a concept position in composed tree and ephemeral range in
composed tree;
"ephemeral" means range in composed tree isn't live. Ephemeral range
objects aren't update at
DOM mutation.

A continuation position, e.g. highlight find result, is specified by
composed tree position but
implemented in collapsed range, since positions in composed tree can be
represented by DOM
node position.

>From implementation, FindText.cursor is very expensive, UA needs to
serialize DOM nodes to
plain text to get DOM node and offset. Note: Blink has an implementation
for this called
PlainTextRange for IME API.

I would like to proposed FindText API to be defined top on Text Iteration
API or Plain Text Serialization
API, both of them aren't specified yet, instead of Node.textContent. These
API can define
HTMLElement.innerText, not standard but most of UA have it and causes
interoperability issue,
and plain text format of clipboard.

-yosi

Just FYI: Here is a presentation from Yandex presented on last November on
Blink On conference:
*
https://docs.google.com/presentation/d/18UHSNEqkFW2toj7Qfo5CcuTuQsFLOibbAMq2VSWoE4I/edit?usp=sharing
*
https://docs.google.com/document/d/1HlPDpwXzzuKp0n5qkKaIL9mYkjtlQHD37OF5pHQuXtE/edit?usp=sharing







2015年10月7日(水) 7:55 Doug Schepers :

> Hi, Tab–
>
> Thanks for the correction. I assumed that Houdini would expose more of
> the underpinnings of the ::selection pseudo-element [1] and its ilk.
> Maybe that hasn't surfaced (and maybe it won't). It does seem to be more
> magic, though, which I'd thought we were trying to demystify.
>
> But if there's no good story in Shadow DOM for things that explicitly
> deal with Range, I think that needs a solution.
>
>
> FWIW, JavaScript source-maps can comfortably deal with a similar
> problem, with minified/cached versions of multiple source documents
> (though I guess not multiple instantiations of the same source
> document). Still, I'd expect there's a non-terrible solution for
> serializing and expanding Shadow DOMs and pinpointing specific
> instantiations.
>
> (This makes me wonder how Shadow DOM is dealing with accessibility APIs;
> I'm assuming there's a good story there, and maybe something we can draw
> upon.)
>
> [1] https://drafts.csswg.org/css-pseudo-4/#highlight-selectors
>
> Regards–
> –Doug
>
> On 10/6/15 6:38 PM, Tab Atkins Jr. wrote:
> > On Tue, Oct 6, 2015 at 3:34 PM, Doug Schepers  wrote:
> >> 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.
> >
> > CSS doesn't care about this, because it doesn't expose its selections
> > to the wider DOM; it can freely style whatever it wants, including
> > ranges that span into shadows.
> >
> > This is indeed equivalent to the problem that the generic Selection
> > API has with Shadow DOM, tho.
> >
> > ~TJ
> >
>
>

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

[Doug Schepers]

Hi, Tab–

Thanks for the correction. I assumed that Houdini would expose more of 
the underpinnings of the ::selection pseudo-element [1] and its ilk. 
Maybe that hasn't surfaced (and maybe it won't). It does seem to be more 
magic, though, which I'd thought we were trying to demystify.


But if there's no good story in Shadow DOM for things that explicitly 
deal with Range, I think that needs a solution.



FWIW, JavaScript source-maps can comfortably deal with a similar 
problem, with minified/cached versions of multiple source documents 
(though I guess not multiple instantiations of the same source 
document). Still, I'd expect there's a non-terrible solution for 
serializing and expanding Shadow DOMs and pinpointing specific 
instantiations.


(This makes me wonder how Shadow DOM is dealing with accessibility APIs; 
I'm assuming there's a good story there, and maybe something we can draw 
upon.)


[1] https://drafts.csswg.org/css-pseudo-4/#highlight-selectors

Regards–
–Doug

On 10/6/15 6:38 PM, Tab Atkins Jr. wrote:

On Tue, Oct 6, 2015 at 3:34 PM, Doug Schepers  wrote:

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.


CSS doesn't care about this, because it doesn't expose its selections
to the wider DOM; it can freely style whatever it wants, including
ranges that span into shadows.

This is indeed equivalent to the problem that the generic Selection
API has with Shadow DOM, tho.

~TJ

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

[Tab Atkins Jr.]

On Tue, Oct 6, 2015 at 3:34 PM, Doug Schepers  wrote:
> 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.

CSS doesn't care about this, because it doesn't expose its selections
to the wider DOM; it can freely style whatever it wants, including
ranges that span into shadows.

This is indeed equivalent to the problem that the generic Selection
API has with Shadow DOM, tho.

~TJ

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

[Doug Schepers]

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" 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 
@fjhirsch

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

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

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

[Elliott Sprehn]

How does this work with shadow dom? Range is not very friendly to that.
On Oct 6, 2015 4:35 PM, "Frederick Hirsch"  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
> @fjhirsch
>
> [1] http://www.w3.org/2014/06/webapps-charter.html#deliverables
>
> [2] http://www.w3.org/annotation/charter/#scope
>
>
>
>
>
>
>