Re: Meeting for selection API at TPAC?

[Yoshifumi Inoue]

Sorry for late response.

I would like to discuss following topics:
1. Selection for Shadow DOM
2. Multiple Range support
3. Resolution of open issues towards FPWD

- yosi

2016年3月15日(火) 9:21 Ryosuke Niwa :

> Hi all,
>
> Is there any interest in discussing selection API at TPAC?
>
> There are 32 open issues on Github at the moment:
> https://github.com/w3c/selection-api/issues
>
> - R. Niwa
>
>
>

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: Should minimal contentEditable default text input (was: contentEditable=minimal)

[Yoshifumi Inoue]

Range.style is cool idea! I assume Range.detach() removes styles added
Range.style.
To implement text composition with this, I would like to have wave
underline, dotted underline, thick underline etc.
Example:: http://www.w3.org/TR/2012/WD-ime-api-20120524/images/image13.png

Also, we can use Range.style for highlighting find result and spelling
error.
-yosi



On Fri, May 23, 2014 at 8:39 PM, Robin Berjon ro...@w3.org wrote:

 Starting a new thread for this specific topic as I think it's one of the
 important early points of contention.

 On 22/05/2014 12:59 , Piotr Koszuliński wrote:

 3. Typing characters. It works in textarea and I think it should work
 out of the box in cE=minimal. Otherwise, cE=minimal will be useless for
 simple cases (mentioned Twitter), because you'll always need a pretty
 complex library to handle text input. Additionally, I don't remember any
 problem with typing characters, so this seems to  work well already in
 cE=true. There's also the IME which scares me, but I don't have any
 experience with it.



 I hear your point about essentially making simple things simple, but I
 really want to resist supporting as much built-in behaviour as possible. Of
 course, it's a trade-off, but I think we should strive for the smallest
 possible amount of behaviour. Note that 1) the complexity of simple things
 by and large depends on the quality of the primitives we provide and 2) on
 the interoperability of what is supported. And the simpler the
 functionality, the more easily interoperable.

 Inserting text as the default behaviour for text input events has
 implications:

 Things get very weird if you support it when you have a caret (i.e. a
 collapsed selection) but not when you have a selection. And a selection can
 have arbitrary endpoints around and into an element. This means that typing
 with an active selection can do more than add some text to a node: it can
 delete or modify elements. Sure enough this can be described interoperably,
 but it does bring us back to issues we dislike.

 It also means that the browser needs to handle composition and its
 rendering, which while it is ongoing may produce relatively weird states in
 the DOM.

 I agree that the Twitter box is a good very basic example. It basically
 needs:

   1) Words that start with @ or # to be a specific colour.
   2) Links to be a different colour, and to have their characters counted
 as the shortened link rather than the full thing.
   3) Newlines must be taken into account.
   4) Characters beyond 140 are highlighted in red.

 I'm ignoring complications with files and the such. In fact, for the
 purpose of our use case it is only useful IMHO to look at how best to
 handle (3) and (4).

 I tried to bang together some code that would do the Twitter box, adding a
 few features along the way and documenting assumptions and issues. It looks
 like that (untested, off the top of my head):

 https://gist.github.com/darobin/8a128f05106d0e02717b#file-twitter-html

 It looks a bit scary, but if you remove the part that handles excess text
 and the wordy comments, you just get:


 https://gist.github.com/darobin/8a128f05106d0e02717b#
 file-like-textarea-html

 Granted, that's still a fair bit of boilerplate. But I think we have to
 take into account the following:

   • This is meant to be low-level. I'm happy to make things easier but
 only so long as we don't introduce magic.

   • We can make introduce some convenience methods for the non-obvious
 parts of the boilerplate. Just having Selection.replace(node|text...) or
 something like new Range(sNode, sOffset, eNode, eOffset) would make things
 a lot nicer.

 It's likely I've forgotten stuff though (notably paste filtering, which
 I'm unsure how to best handle here — see comments). Please review the code
 so that we have an idea for a baseline of what we'd like to get at the end.

 --
 Robin Berjon - http://berjon.com/ - @robinberjon

Re: contentEditable=minimal

[Yoshifumi Inoue]

Thanks Jonas for clarification. Now, I understand contentEditable=minmal
doesn't modify DOM.

For drawing IME UI, text composition, Blink inserts text node with text
decoration to display on going text composition, IME UI. So, implementing
contentEditable=minimal, Blink should remove text nodes at commit of text
composition and dispatch text input event along with beforeinput.Is this
correct?

-yosi


On Thu, May 22, 2014 at 5:52 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Thu, May 1, 2014 at 5:31 PM, Ben Peters ben.pet...@microsoft.com
 wrote:
  Proposal
  To make this simpler for sites, frameworks, and browsers, it makes sense
 to enable a new, simpler version of contentEditable that provides basic
 functionality only. For the sake of discussion, call it
 contentEditable='minimal'. The functionality provided by the browser under
 contentEditable='minimal' would be as follows:
  * Caret drawing
  * Events such as Keyboard , Clipboard, Drag and Drop
  * Some keyboard input handling- caret movement, typing of characters
 including Input Method Editor input
  * Selection drawing and manipulation according to the new Selection API
 spec

 This sounds like a super promising approach.

 If I understand the proposal correctly, when the user does something
 that causes input, like pressing the enter key, we would fire a key
 event, but we wouldn't actually modify the DOM. Modifying the DOM
 would be the responsibility of the web page.

 Likewise, if the user pressed whatever key is platform convention for
 paste, we would fire an event which contains the clipboard data, but
 not mutate the DOM. Copying data from the event (i.e. from the
 clipboard) to the page would be the responsibility of the page.

 Is that correct? If so I like it a lot!

 I'd like to expand, and clarify, the list of services that you propose
 that the UA provides:

 * Caret and selection drawing.
 * Drawing IME UI in response to user typing.
 * Events for clipboard and drag'n'drop (though the UA would not mutate
 the DOM in response to those events).
 * Cursor navigation, including reacting to touch events, mouse clicks
 and keyboard events. Cursor navigation would likely also fire
 cancelable events.
 * Turning keyboard events into events representing text input (but not
 mutate the DOM in response to those events).
 * The Selection API spec for selection manipulation.

 I.e. pressing a key on the keyboard would always fire a keyboard
 event, and then, as default action, possibly a cursor navigation event
 or a text input event, depending on what type of key was pressed.

 I'm unsure about what the proper way to handle text insertion is. I.e.
 how to handle the second to last bullet.

 Can we simply use the same events as we fire in input type=text and
 textarea, but don't actually mutate any DOM? Or is it awkward to
 fire beforeinput when there is no default action of mutating the DOM
 and firing input?

 And is it too much complexity to ask pages to deal with composition
 handling themselves?

 Another approach would be to allow plain text input events to actually
 mutate the DOM as a default action. But allow that action to be
 cancelled. Note that we would never do anything more complex than
 mutate an existing text node, or insert a text node where the cursor
 is located. I.e. no elements would ever get added, removed, split,
 have attributes changed or otherwise be mutated.

 But if we can make the code that a page needs to write in order to
 handle the text mutation relatively simple, even when handling
 composition, then I think we should leave it up to the page.

 / Jonas