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

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 <schepers@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 <schepers@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
> >
>
>