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 <schep...@w3.org
<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 <schep...@w3.org
<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
>
