Re: time at TPAC other than Wednesday?

+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>
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

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


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

==========

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




>
> ---------- 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
>
>