Fwd: time at TPAC other than Wednesday?

Just so we don't have too many different ideas about what is going on.

This is the last I remember having heard from the taskforce. We were
waiting on answers from the different browser vendors on the issues under
"open issues" before we could move on finishing the most important parts of
the spec, AFAIR. One of the big questions here was what kind of "dumb
ranges" the browser vendors would be willing to support.

But maybe you found answers to those issues at the Redmond meeting? If so,
could you please send over the minutes?



---------- Forwarded message ----------
From: Gary Kačmarčík (Кошмарчик) <garykac@google.com>
Date: Wed, Nov 4, 2015 at 11:32 PM
Subject: Re: time at TPAC other than Wednesday?
To: Johannes Wilm <johanneswilm@gmail.com>
Cc: Travis Leithead <travis.leithead@microsoft.com>, chaals@yandex-team.ru,
Ryosuke Niwa <rniwa@apple.com>, Koji Ishii <kojiishi@gmail.com>, Xiaoqian
Cindy Wu <xiaoqian@w3.org>, Grisha Lyukshin <glyuk@microsoft.com>, Ojan
Vafai <ojan@google.com>


These are my notes, with the final Summary at the top as a tl;dr. Sorry for
any oddities in formatting.  Please respond with any
corrections/clarifications.

-Gary



*Before input and Composition Events*
9:30 Wed
Present: Ryosuke Niwa, Travis Leithead, Takayoshi Kochi, Johannes Wilm,
Ojan Vafai, Koji Ishii, Gary Kacmarcik, Yoshifume Inoue, Yoichi Osato,
Dominic Cooney
Dialed in: Grisha Lyukshin

*# Summary of meeting:*

# Open Issues
need to create proposal for when comp events fire for IME
esp. when user overflows IME buffer
composition partial updates
need to decide what kind of range to use:
live ranges
DumbRange (StaticRange)
need to decide single vs. multiple ranges
consider a new element for editable content
replace contentEditable
we could attach editing context to the element
# Bugs
beforeinput/input should fire for contenteditable
for all editable things
broken on some browsers

# Agreed
target range should always be populated


*# Agenda*

Review proposals
ryosuke's - does it work
beforeinput/input
naming
beforeedit
edit types
compositionevents

# Todo later
decide where the spec for this should live

We won't have time for all of these, so let's start with beforeinput/input.


*# Notes*

you (js dev) don't know what the browser is going to happen when the char
gets inserted
eg:
<a> text </a> more
       ^    ^
where is insertion point?
browsers disagree

right now 'input' event is around a session
but spellchecking doesn't have a session
spellcheck does not currently fire a 'input' event
but if you do that, it changes the semantics of 'input'

'beforeinput' 'input'
should always have target ranges

case study: medium.com
they build a native mobile app because this was broken on Android

'input' event fires for input element and textarea element
device independent events

for contenteditable
user type 'h'
send device independent event: "please insert 'h'"
with info on where to insert
app inserts 'h'

ojan: contenteditable=true exists and we should make it good
beforeinput
compositionevent
input
- these should all have the context info
problems:
ordering of events
ryo: ideal world
no composition event, only input event
at comp-end, we commit the composition

main confusing:
'input' and 'textarea'

is it ok for events to be different for content-editable vs. for
input/textarea?
content-editable is where you can do rich things
it has more context info
for input/textarea, this is less important

proposed IDL
interface InputEvents
offsets for input/textarea -- we can punt this for v1
ranges for contenteditable

include this info (the ranges) for composition events as well.
c-start, c-update and c-end

3 examples - what is range:
insert a
collapsed range
delete a
range surrounding 'a'
replace a with b
range surrounding 'a'
in IME composition
今日は
＾＾
こんにち
range:
c-update: entire string
input: entire string

trying to avoid having 2 ranges:
full range
current selected text

E.g.: IME supports length of max 4
A B C D
^^^^^^^
type Z
'A' is committed
comp-end 'A'
comp-start 'BCD'
comp-update
A X C Y Z
 ^^^^^^^
input 'BCD' -> 'XCYZ'

Chrome fires:
c-end 'A'
c-start for 'BCD' (but doens't give text because it is known)

Summary:

use input and beforeinput and comp events
fire for content-editable=true, input and textarea
extend these events with fields:
target ranges
beforeinput will have:
isComposing
data

order of events needs to be spec'ed

before input:
IME API
what if instead of target range, we exposed editing context
target ranges only for now
eventually add IME candidate window.
concept:
a single IME associated with the DOC
no compelling argument for container for IME

beforeinput target ranges:
"the ranges in the doc that are affected by this event, unless related to
current selection"
target range is selected range
except for comp-event, where it is the entire range


dead ranges
live ranges are expensive:
need to be kept up to date
add code complexity
there will be resistance to adding new live ranges

we should add a new "dumbed-down" range like thing
rather than use a live range
just a node+offset, node+offset
"dumb range"

can we just use a selection?
people commonly use range as range.get(0)

input and beforeinput need multiple ranges to support block selection
composition events only need a single range

for v1:
we will have a range (range or StaticRange)
this range is always populated

DumbRange {
startNode;
startOffset;
endNode;
endOffset;
isCollapsed;
}
perhaps: "static range"
to parallel: list and static list



editTypes:

list of MS edittypes looks like a subset of execCommand.
sounds like we need all the execcommands

app needs to define what is supports

scenario:
ios word processor
has bold icon on soft keyboard
press bold to bold text
but for a text editor
doesn't support bold
doesn't make sense to show the bold icon

so app should register for the events that they want/can handle

what about if a new command was added
if apps have to opt-in, they will not get it
even though it might just work out of the box
what about opt-out?
app wants to disable cut-copy-paste, but keep everything else
it doesn't want to opt-in to each new

in ios currently, you declare a list of things that you support on the
keyboard

ios can't query for supported commands before the keyboard appears
but it can do it when the object gets focus

with a JS api
you could have opt-in, opt-out
could attach to global IME object
but 'copy' can apply to non-content-editable


what about document.keyboard
api: bring up keyboard
other kb attributes
what about a new element to replace content editable?

-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org