Re: Outcomes from Informal Editing meeting on 7th Jan 2016

On Wed, Jan 13, 2016 at 3:01 AM, Grisha Lyukshin <glyuk@microsoft.com>
wrote:

> 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*
> <http://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>
>

Ok, so a lot of this seems to be about moving large parts of the spec into
the UI events spec. Right now the division is:

contentEditable: explains the three new contentEditable types (caret,
events, intentions) and points to contentEditable=True document for a
description of the existing stuff. Of the three new editing types we will
only describe one  in detail at this time and implement that one. But which
one that is changed about 3 times per week.

inputEvents: Describes the beforeInput and Input events + has some
information about the order of events in relation to compositions.

UI events: mentions the order of beforeInput/Input in relation to other
events.


Now if I understand you correctly, you would like to change this to:

contentEditable spec: holds the list of events of the beforeInput/Input
event. Continues to describe the new type of contentEditable.

UI events: holds everything else about the event.


I personally don't mind how to do it, but I wonder if the only thing we
have of that event is the list of edit types, and we put it into a
"contentEditable" spec, but it really also applies to <input type=text> and
textarea, is that really making it less confusing? If we do move the event
into the UI events spec, then maybe we should move the entire thing,
including the list of edit operations there?

Else we end up with a spec that half-describes two different types of
contentEditable and one fully, and has a small part of the information
relevant for an event that is described in another spec and is relevant for
elements that aren't contetnEditable at all.




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

Can you explain this a little more? What is the isComposing field to hold?

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

If everything about the event has been moved to UI events except the lsit
of InputTypes, wouldn't this also be in the UI events spec?


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

This sounds like you will want to have another part of the event described
in the contentEditable spec, correct? Wouldn't it be confusing if this data
attribute is described in one spec if it's about "text/plain" and in
another if it's about line breaks? Could you also explain udner what
circumstances the data attribute is being used?


>
>    -    We should  ensure drag/drop also fires beforeInput - *#107*
>    <https://github.com/w3c/editing/issues/107>
>
>
This would go into the UI events spec, right?


>    -    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>
>
>
See description in last email. We can take the discussion on whether we can
merge something more now, or another option is to try to move ahead with
beforeInput and then look at this again in half a year when there may be
more clarity on what the future of these different contentEditable types is
going to be.


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



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