W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2015

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

From: Doug Schepers <schepers@w3.org>
Date: Wed, 7 Oct 2015 01:48:15 -0400
To: Yoshifumi Inoue <yosin@google.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Elliott Sprehn <esprehn@chromium.org>, Frederick Hirsch <w3c@fjhirsch.com>, public-webapps <public-webapps@w3.org>, W3C Public Annotation List <public-annotation@w3.org>
Message-ID: <5614B21E.6020701@w3.org>
Hi, Yosi–

On 10/6/15 9:30 PM, Yoshifumi Inoue wrote:
> 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.

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.


> 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:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:58 UTC