meeting notes, 2020-09-11

[18:08] <johanneswilm> Bo: progress on editcontext + virtual context. want
to talk about tpac
[18:08] <johanneswilm> we want to address caret movement in rel to
exitcontext
[18:10] <BoCupp> zakim, start the meeting
[18:11] <johanneswilm> alex demos keyboard event viewer for editcontext
[18:11] <BoCupp> Zakim, start the meeting
[18:11] <johanneswilm> alex shows vertical caret movement with just a few
lines of code
[18:12] <johanneswilm> s/vertical/horizontal
[18:15] <johanneswilm> Alex: should we sync mouse-caused changes to
selection to selection in buffer?
[18:15] <johanneswilm> bo: no, this should be up to author
[18:17] <johanneswilm> alex: we have implemented drag/drop of words
[18:17] <johanneswilm> the dom will remain unchanged, but we will fire the
event
[18:20] <johanneswilm> Anupam: do you have format updates?
[18:20] <johanneswilm> Alex: yes
[18:21] <johanneswilm> Alex: nothign for textformatupdate
[18:21] <johanneswilm> wenson: why is the candidate window in the right
place? does it follow native selection?
[18:21] <johanneswilm> Alex: yes
[18:22] <johanneswilm> Bo: editcontext reports it's position
[18:22] <johanneswilm> Wenson: is it a single rect? multiple rects?
[18:22] <johanneswilm> Alex: single rect
[18:23] <johanneswilm> Bo: selection could be several rectangles, but only
one is important
[18:24] <johanneswilm> Johannes: Can you handle vertical movement?
[18:24] <johanneswilm> Alex: no
[18:26] <johanneswilm> Bo: we have divided it into content based movement
and layout based movement. We don't handle layout based so far. that was
our thinking so far.... but if we use the native selection...
[18:26] <johanneswilm> Bo: We could allow movement of the native selection
in native layout....
[18:30] <johanneswilm> johannes: It would be ok to have the information
about where the range would go if going up and down from a given range as
something entirely separate from editContext
[18:30] <johanneswilm> Bo: I see, but we might just make that possible. Let
us think about it.
[18:32] <johanneswilm> Alex shows editcontext with three views for the same
editbuffer.
[18:32] <johanneswilm> Alex: even the IME underlining, etc. are shown in
all three
[18:33] <johanneswilm> Alex the candidate window only shows up of the three.
[18:34] <johanneswilm> Bo: The candidate window will show up where you
decide to report the position
[18:34] <johanneswilm> Alex shows pagination demo
[18:35] <johanneswilm> Alex: when showing text at end of one page and wants
to type Chinese with IME. Demo shows we can compose across page boundaries.
[18:36] <johanneswilm> Bo: Author needs to program this though, right?
[18:36] <johanneswilm> Alex: should we show more
[18:36] <johanneswilm> Bo: no, this is great
[18:37] <johanneswilm> Bo: this operation would have cancelled composition
before.
[18:38] <johanneswilm> Bo: if you had a hidden cE-element, you don't get
enough information to render everything correctly
[18:38] <johanneswilm> Alex: should we give authors helpers?
[18:41] <johanneswilm> Johannes: footnotes that get too large for one page
and need to be moved are another example. You might want to create a demo
editor, but likely there will be JS libraries created on to-p of this that
everyone will use.
[18:42] <johanneswilm> Alex shows dictation demo
[18:43] <johanneswilm> Bo: in dictation there is a lot of text that is
indiscomposed state that needs to break around boundaries, etc.
[18:50] <johanneswilm> Anupam shows virtual keyboard demo
[18:50] <johanneswilm> Anupam shows demo on virtual keyboard policy
[18:51] <johanneswilm> shows difference between behavior of values auto and
manual
[18:52] <johanneswilm> manual does not change state of keyboard
[18:53] <johanneswilm> user can form and the keybaord does not show up.
when it is "auto", keyboard shows up automatically. default is "auto"
[18:53] <johanneswilm> focusing on "readonly" makes keyboard go away
[18:54] <johanneswilm> focusing on "manual" makes it stay or go away, which
ever was the previous state
[18:59] <johanneswilm> Wenson: does show() return any promise? I think
there might be value for us not to allow keyboard to show up unless there
is user gesture
[19:00] <johanneswilm> johanneswilm: terms in contenteditable-discussion.
FYI: https://github.com/whatwg/html/issues/5863
[19:01] <johanneswilm> Bo shows demo on second part of
virtualkeyboardpolicy - JS can tell if keyboard is there or not. That makes
it possible to adjust scrolling accordingly.
[19:02] <johanneswilm> There is an event for virtualkeyboard
appearing/disappearing. In demo we used css environment variables to adjust
for keyboard appearing/disappearing
[19:04] <johanneswilm> Wenson: you can also check visual viewport
[19:04] <johanneswilm> Bo: tpac
[19:05] <johanneswilm> Bo: people are scehduling meetings self-organzied
around the planet
[19:05] <johanneswilm> there are also publically attended meetings on the
breakout day
[19:07] <johanneswilm> Bo will send email to mailing list about tpac

-- 
Johannes Wilm
http://www.johanneswilm.org
tel: +1 (520) 399 8880