Re: time at TPAC other than Wednesday?

On Sat, Jan 9, 2016 at 2:32 AM, Gary Kačmarčík (Кошмарчик) <
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>
> 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.
>

Ok, thanks.

However, please be aware that the rules actually require for these meetings
to be announced on this email list. Now I understand you had a meeting
about another spec which is not part of this editing taskforce, but you did
go on to discuss the work maintained by this taskforce. If we just do it
that everyone calls their own meetings without announcing them to the other
ones involved, we can skip all formality of having task forces and W3C
altogether.

Now I am myself rather flexible, and I'm glad to see this is still moving
forward almost no matter how. I haven't looked at what you came up with
yet, and I just hope it doesn't conflict with what some who weren't present
feel strongly about, because then we do have a problem.


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


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