RE: time at TPAC other than Wednesday?

Hello Johannes,

I was the one to organize the meeting. To make things clear, this was an ad hoc meeting with the intent for the browsers to resolve any ambiguities and questions on beforeInput spec, which we did. This was the reason I invited representatives from each browser only.

To your question about removing ContentEditable=”true”. The idea is consolidate multiple documents into a single editing specification document. We wanted to remove ContentEditable=”true” because it had no content there. So resolutions on CE=true from previous meetings remain unchanged. There is no point on having empty document floating on the web. So yeah, we wanted to remove the draft that has no content. We will merge Input Events and other ContentEditable specs into a single spec. We didn’t really have any discussions on execCommands spec.

P.S. I’ll be sure to include any interested parties in the future. This time was more of how do we implement something that web devs want so it is interoperable among browsers.


--grisha


From: johanneswilm@gmail.com [mailto:johanneswilm@gmail.com] On Behalf Of Johannes Wilm
Sent: Friday, January 8, 2016 6:09 PM
To: Gary Kačmarčík (Кошмарчик) <garykac@google.com>
Cc: public-editing-tf@w3.org; public-webapps@w3.org
Subject: Re: time at TPAC other than Wednesday?

On Sat, Jan 9, 2016 at 2:32 AM, Gary Kačmarčík (Кошмарчик) <garykac@google.com<mailto:garykac@google.com>> wrote:
+public-webapps since these these notes are relevant for both groups

On Fri, Jan 8, 2016 at 5:03 PM, Johannes Wilm <johannes@fiduswriter.org<mailto:johannes@fiduswriter.org>> wrote:
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.

The good news is that the range issue has been resolved by removing them from the event. See the notes below for more info.

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

Good timing. I was just finishing up my notes (see below) from the meeting.

-Gary


This is a summary of my notes from the beforeinput/editing summit hosted by Microsoft on 7 Jan 2016.
These notes focus on the UIEvent/beforeinput discussions, but some of the editing discussions are included here as well.

Spec location
==========
UIEvent spec will contain core description of beforeinput
data, isComposing
the data property should contain the text/plain version
will define the event ordering
Editing spec will contain partial interface that adds editing-specific stuff:
editType (renamed to inputType)
dataTransfer field (for handling rich data)

What about selection ranges for beforeinput?
==========
We determined that this was not needed as an attribute on the InputEvent.
If you need the range, you call a getTargetRanges() method and get a static snapshot of the current ranges


Where can one find more information about getTargetRanges() method? This is a method on the event object, right?

For most of the cases one can get of course get current range with window.getSelection() and then selection.getRangeAt(0) . But the point with the ranges on the event was that it may affect a range that is not equal to the current selection range (such as a spell checker, etc.). We discussed this in Paris.

So if I understand you right, with getTargetRanges() I can get the range of the word that is being spell checked without changing the selection range? The only reason it is a method of its own is so that one only creates the "live range" if the user really really asks for it, right?


Usually there will be only 1 range, but an array is returned to handle multirange.
This avoids many problems associated with including targetRanges on the event, e,g:
Should the range be live or static?
Live ranges can be expensive to upkeep and they are often held onto longer than intended
A lighter-weight StaticRange would need to be defined
How to handle multiple handlers for an event, when the first handler in chain modifies DOM or selection.
What range should be sent to the 2nd handler?
We need to send same event to each handler in the chain
Therefore followup events will need to be sent an incorrect range.
Ugh

Order of compositionupdate and beforeinput events
==========
Current UIEvent spec says compositionupdate fires before beforeinput
What is the point of beforeinput *after* compositionend?
it seems unnecessary
It makes more sense for the event order to be:
beforeinput
compositionupdate
input
Update UIEvent spec with the new event ordering

Agreed. I think the main reason for this order was that there was a believe that the IME was so much in control that it would fire the compositionupdate event by itself and without the browser having any control over it.


When should DOM be updated during composition?
==========
Current browser behavior:
IE/edge fire compositionupdate after the DOM has been modified
Moz/Saf/Chrome fire it before the DOM has been modified.
We should define when the DOM is updated explicltly in the spec:
beforeinput
compositionupdate
-- update DOM
input

beforeinput/input during composition

makes sense

==========
WRT composition, beforeinput and input should not fire:
before compositionstart
after compositionend
beforeinput/input events should wrap all compositionupdates

Composition events
==========
There must be at least one compositionupdate after compositionstart
There must be at least one compositionupdate before compositionend
The same compositionupdate can satisfy both requirements

keyboard events during composition
==========
general thought was that it didn't make sense to suppress these
isComposing flag can be used to ignore if needed
currenly only FireFox suppresses keydown/keyup during composition
Mozilla was not present, so we need to follow-up

dead keys as composition events
==========
current browser behavior:
on Mac, all browsers generate composition events for dead keys
on Win, no browsers generate composition events for dead keys
current spec says that dead keys should generate composition events
need to confirm that there are technical issues making this difficult to do on Win


That all looks good to me.

Now what about the part of what is going to happen to contentEditable=True? And what exactly did you talk about in concerns of that? DO you want to kill? Do you want the "draft" spec to go away? Is it only cE=true or also execCommand?






---------- Forwarded message ----------
From: Gary Kačmarčík (Кошмарчик) <garykac@google.com<mailto: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<mailto:johanneswilm@gmail.com>>
Cc: Travis Leithead <travis.leithead@microsoft.com<mailto:travis.leithead@microsoft.com>>, chaals@yandex-team.ru<mailto:chaals@yandex-team.ru>, Ryosuke Niwa <rniwa@apple.com<mailto:rniwa@apple.com>>, Koji Ishii <kojiishi@gmail.com<mailto:kojiishi@gmail.com>>, Xiaoqian Cindy Wu <xiaoqian@w3.org<mailto:xiaoqian@w3.org>>, Grisha Lyukshin <glyuk@microsoft.com<mailto:glyuk@microsoft.com>>, Ojan Vafai <ojan@google.com<mailto: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<http://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<http://www.fiduswriter.org/>





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