Re: Proposal + Paris F2F Meetup

On Wed, Jul 22, 2015 at 1:55 PM, Frederico Knabben <f.knabben@cksource.com>
wrote:

>  While preparing for the F2F meetup in Paris, I’ve noticed that we may
> fail on achieving anything. The cE=typing topic got a bit confusing, with
> no clear direction and it sounds like we’ll not have time to put order on
> all this.
>
> This is my proposal for today's focus of the TF, so we cold finalize the
> specs in Paris.
>
>
> *1. Drop contenteditable=“typing”*
>
> The typing thing became a big topic. It is fragmented into several
> different aspects that need a lot of discussion. Recently we even saw
> uncertainty whether some aspects, like caret movement, should be part of
> this specs or the Selection API.
>
> Because of the complexity, I propose to drop it (but wait, read further).
>
> ...


>
> *3. Introduce contenteditable=“intent”*
>
> This is something discussed a lot previously with Ben and in a very
> advanced stage. This module would enable the Intent API into cE. With this,
> no behaviour is expected in the editable but a strong events API of user
> “intents” take place. The behaviour would be then implemented by JavaScript
> developers on top of the events.
>
>

Exchanging the name contenteditable="typing" with contenteditable="intent"
is fine with me, given that the following two issues are handled:

A) There was one main reason to allow direct input (not just intents) and
therefore for the name cE=typing, and that was inline-IME. As I understand
the browser makers' comments, they have figured out how to be able to
obtain inline-IME input without changing the DOM (using shadow dom or other
technologies) which can be transformed into a series of input intent events
after the composition process has terminated [1].

B) There was also one reason to allow caret movement via arrow keys,
because doing movement of the caret in the block direction via JavaScript
is difficult to impossible. The main issue here is that the JS cannot
determine the precise location of the caret when it is at line end or
start. Ryosuke Niwa has made a proposal to handle this in the selection API
[2]. It would be good if we could agree on putting this into the Selection
Api spec or one of the others.

With that issue out of the way, I don't think there is any reason why not
to change the name. Is there anything about the contents of the spec that
should still be changed, Frederico?



>
> *2. Introduce the concept of “modules” in contenteditable*
>
> I think this is not a spec’ed concept but we’ve been talking about it. So
> let’s spec it.
>
> The idea is that “typing” would be a module, just like “line-break”,
> “clipboard”, etc.
>
> And ofc, the “intent” module.
>
>
Ok, where should this go? Into the "contenteditable" draft [3]? For now the
intent module would be the only module, right?

What about the input events spec [4]? Should we rely on just catching
keypress events, etc. and polyfill the input intents spec, or should we
move on towards recommendation of that spec?


>
> *Conclusion*
>
> The proposed approach would simplify the specs considerably, as for now.
> We would be able to come with a recommendation.
>
> The goal is introducing the necessary API for all other cE modules to be
> implemented. At a fist stage, such modules would appear as JavaScript
> libraries which, later on, may be converted into specs.
>
> If accepted, we should discuss this approach and move it forward as much
> as we can, leaving for Paris the final critical parts of it… or nothing, so
> we’ll just take the opportunity to bring it to a broader audience, confirm
> it and celebrate it.
>
> Is this a good way to go?
>
>
As long as we have the needed primitives to do everything else in
Javascript, I think this is the best approach that both guarantees us on
the JS side of things that we get something that is actually interoperable
and doesn't have to go throuugh another 5-15 years of spec'ing and
browserside development, and at the same time guarantees the browser makers
that they don't have to waste time this early on on higher level editing
features before they have been thoroughly defined and tested by the
different JS editor makers.


[1] https://github.com/w3c/editing/issues/57
[2] https://github.com/w3c/selection-api/issues/32
[3] https://w3c.github.io/editing/contentEditable.html
[4] https://w3c.github.io/editing/input-events.html

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