Re: web input model (was "Re: The web doesn't need...")

I found it very interesting to observe how our discussions before and on
the F2F meeting in Paris went and how the spec's been changed thanks to
that.

* A month ago we've been talking about cE=caret when the browser renders a
caret but caret movements are implemented in JavaScript.
* Then we realised that *correctly* implementing selection movements in
JavaScript is a job that only a few people could do. Handling RTL/LTR
boundaries, touch devices (and other ways to control the selection),
localisation, platform specific behaviours, complex layouts (multi-col,
floats) and few other things that are currently hidden by browsers (e.g.
the "x position" and "before/after soft line break"). We agreed that some
of these internals need to be exposed, but we decided that browsers will
implement selection control.
* At that point we still talked about handling typing with JS, not by the
browser. The only problem was composition.
* As we discussed this, we realised how complex composition is (how many
variants of it you can have) and that it's not only browser specific, but
rather OS & configuration specific (e.g. different IMEs on Linux). At the
end of the day we were talking about cE=typing :). So the browser takes
control over composition and text insertion, but it can be controlled with
JS.

I think it was a big win. We ended up with a sane model where the browser
exposes nice APIs which can be used to tune up its behaviours, but it
doesn't force you to control things you cannot control now and which would
be very hard to expose. This can be of course done in the future, but for
now we will not think about it.

>  These seem like desirable input-model capabilities for non-editing
applications, too.

I hope the above explains a bit why we ended up with such a model (oriented
around "editing"). I remember some voices at the beginning (about a year
ago) that we could try to generalise these to cover other types of
applications (like image/music editing software for instance – if that's
what you meant), but I think that text editing is somehow special here.
However, if I understood you correctly, you may be interested in
http://www.w3.org/WAI/IndieUI/.


On Wed, Sep 9, 2015 at 5:45 PM, David Young <dyoung@pobox.com> wrote:

> On Wed, Sep 09, 2015 at 01:52:22PM +0200, Piotr Koszuliński wrote:
> > > 1. It is possible to write client code that implements all of this,
> > without using any contentEditable at all.
> >
> > No, it isn't possible currently. And there's a very long way to go before
> > it'd be possible. I've written an article to explain exactly this
> situation
> > –
> >
> https://medium.com/content-uneditable/contenteditable-the-good-the-bad-and-the-ugly-261a38555e9c
>
> Would you agree that almost all of the obstacles to implementing
> contenteditable in JavaScript reside in the web input model?  As
> you mention in the article, an editor needs to assert keyboard
> focus, to avoid *accidentally* intercepting or conflicting with
> OS/browser key-chords and -compositions, and to *purposefully*
> suppress/override certain platform key combinations.  These seem like
> desirable input-model capabilities for non-editing applications, too.
>
> Dave
>
> --
> David Young
> dyoung@pobox.com    Urbana, IL    (217) 721-9981
>
>
>


-- 
Piotrek Koszuliński
CKEditor JavaScript Lead Developer
--
CKSource - http://cksource.com
--
Follow CKEditor on: Twitter <http://twitter.com/ckeditor> | Facebook
<http://www.facebook.com/ckeditor> | Google+
<https://plus.google.com/107736718646302128806> | LinkedIn
<http://www.linkedin.com/company/cksource>