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

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 <schepers@w3.org
> <mailto: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
>     <mailto: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
>      >
>

Received on Wednesday, 7 October 2015 05:48:22 UTC