Outcomes from Informal Editing meeting on 7th Jan 2016

Hi All,

I would like to take this opportunity to sincerely apologize for misinterpreting the informal Editing meeting we had at Microsoft Campus on 7th Jan 2016 as F2F Task force meeting, We will make sure to adhere to the W3C guidelines moving forward.

To help everyone understand the outcomes of this informal meeting, I am sharing these notes and outcomes with all, I have also documented these as issues on github for public discussion and feedback.

Looking forward to the feedback.


Attendees:
Bo Cupp, Dave Tapuska, Emil Eklund, Enrica Casucci, Gary Kacmarcik,  Grisha Lyukshin, Ian Kilpatrick, Ojan Vafai, Ryosuke Niwa, Myles C. Maxfield.

Agenda:
*     Resolve any ambiguities and disagreements that block shipping v1 of  beforeInput event specification.
*     Live vs dead ranges on new APIs, in particular, on beforeInput event target range.


These are the outcomes that attendees felt was the right course of action, please provide feedback on those.

*     We should Keep beforeInput/input naming as per Sapporo meeting resolutions.
*     beforeInput/input events should be fired for any element with contentEditable enabled, input and textArea elements where input element and textArea will have targetRanges set to null- #96<beforeInput/input%20events%20should%20be%20fired%20for%20any%20element%20with%20contentEditable%20enabled,%20input%20and%20textArea%20elements%20where%20input%20element%20and%20textArea%20will%20have%20targetRanges%20set%20to%20null.>
*     We should rename EditTypes to InputTypes - #97<https://github.com/w3c/editing/issues/97>
*          We should remove EditTypes/InputTypes it from the UI events spec.  It should be specced in editing Spec - #98<https://github.com/w3c/editing/issues/98>
*     Base definition and ordering of beforeInput/input events should be in UI events, but the editing specific stuff should be in a separate editing spec - #99<https://github.com/w3c/editing/issues/99>
*     Cancelable attribute should be removed from the spec because it already referenced in Event.idl - #100<https://github.com/w3c/editing/issues/100>
*     We should fire beforeInput event before compositioinupdate. Reasoning: IE/Edge fire compositionupdate after the DOM has been modified, Moz/Saf/Chrome fire it before the DOM has been modified - #101<https://github.com/w3c/editing/issues/101>
*     Chrome/Safari need to fix a bug. Compositioinupdate is not firing before the compositionend - #102<https://github.com/w3c/editing/issues/102>
*     isComposing field should be consistent with the composition events, no need to redefine it. So just provide a reference to spec - #103<https://github.com/w3c/editing/issues/103>
*     We should update the spec with an ImmutableStaticRange that is a subset of the Range interface and return them via the getTargetRanges method. s/ImmutableStaticRange/StaticRange/ in the actual spec - #104<https://github.com/w3c/editing/issues/104>
*     We could have "data" property that returns the text/plain version and a dataTransfer field for richer things - #105<https://github.com/w3c/editing/issues/105>
*     We should keep data in UI events for beforeInput that does the text/plain serialization. We should add dataTransfer to the editing spec for other mime types(html, text with line breaks, etc) - #106<https://github.com/w3c/editing/issues/106>
*          We should  ensure drag/drop also fires beforeInput - #107<https://github.com/w3c/editing/issues/107>
*          Currently, there are multiple documents that pertain to editing. We should merge all the editing related specs into one - #108<https://github.com/w3c/editing/issues/108>



Open Questions:
*     Should DOM be modified before or after compositionupdate? edge/IE do one thing, chrome/saf/firefox do another - #109<https://github.com/w3c/editing/issues/109>
*     Apps should be able to declare things that they support. Example: for the bold button in the ipad keyboard. So apps should be able to choose to opt-in for any inputType thus, subscribing for this button to be shown. Old issue from previous meeting #93<https://github.com/w3c/editing/issues/93>
*     inputType should be tied to the command names and having that tied to a way of declaring what you support - #110<https://github.com/w3c/editing/issues/110>

--grisha