Re: time at TPAC other than Wednesday?

On Sat, Jan 9, 2016 at 3:49 AM, Grisha Lyukshin <glyuk@microsoft.com> wrote:

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

In so far as to clarify the questions you had at the last meeting that you
needed to resolve with your individual teams, that you had indeed announced
at the meeting that you would talk about --- I think that is fair enough.

I am not 100% familiar with all processes of the W3C, but from what I can
tell, I don't think you can treat it as having been a F2F meeting of this
taskforce, but you can say that you had some informal talks with your and
the other teams about this and now you come back to the taskforce with a
proposal of how to resolve it.

Similarly, among JS editor developers we have been discussing informally
about priorities and how we would like things to work. But those are
informal meetings that cannot override the taskforce meetings.


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

Yes, I don't think that part can reasonably be said to have been part of
something you could resolve in a closed door, unannounced meeting among
only browser vendors.

Both the treatment of the various documents and especially
contentEditable=True has been very controversial in this taskforce in the
past, and I don't think you can just set aside all processes and consensus
methods to change this.

So with all due respect, I don't think you can just delete it like that.
Just as I cannot just delete part of the UI events spec because I have had
a meeting with some people from TinyMCE and CKEditor and we decided we
didn't like that part.


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

As an informal meeting to get some common thoughts I don't think it's a
problem to just have smaller meetings. It's just important to keep that
distinction in mind.



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



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