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