RE: User Intentions Explainer (was: List of Intentions)

Rich Schwerdtfeger

Ben Peters <Ben.Peters@microsoft.com> wrote on 09/19/2014 03:55:46 PM:

> From: Ben Peters <Ben.Peters@microsoft.com>
> To: Piotr Koszuliński <p.koszulinski@cksource.com>, Frederico
> Knabben <f.knabben@cksource.com>
> Cc: Johannes Wilm <johannes@fiduswriter.org>, "public-editing-
> tf@w3.org" <public-editing-tf@w3.org>, Julie Parent
> <jparent@gmail.com>, "public-indie-ui@w3.org" <public-indie-
> ui@w3.org>, public-webapps <public-webapps@w3.org>
> Date: 09/19/2014 03:56 PM
> Subject: RE: User Intentions Explainer (was: List of Intentions)
>
> I agree that we can divide this work, but so far I think we should
> do "2" first. Being able to remove browser functionality with a
> simple API is going to be far quicker to implement (in browsers) and
> provides immediate benefit. Solving Intentions will be a longer
> process, but is also important to really enable performance and
> "extensible-web" scenarios.
>
> On Tue, Sep 9, 2014 at 4:28 AM, Piotr Koszuliński
> <p.koszulinski@cksource.com> wrote:
> > I'm not sure if I remember correctly, but I believe that after long
> > discussions we left the question "what should contenteditable=minimal
be?"
> > unanswered. First the intention events lists should be created, so we
can
> > see what needs to be handled. And this is what Ben Peters is working
on.
> >
> >> Still we may also take in consideration that there are limited
resources
> >> available for working on the specs. Therefore the whole work could be
> >> separated into two *independent* topics:
> >>  1. Intention events + execCommand.
> >>  2. contenteditable=“minimal”
> >
> >
So, you want to modify contenteditable to "minimum". What will that do to
existing apps. that are built on it? We have a number of IBM web
applications that use contenteditable as do many other companies. CKSource
(Piotrek is the lead developer) has an open source product called ckeditor
that IBM contributed accessibility support to and so it is now used by many
large enterprises including Oracle.
A migration strategy is needed for existing consumers of contenteditable.

> > That's what I was proposing as well - to have the base (which consists
> > mainly of fixed selection API and intention events) ready as soon as
> > possible, so hopefully browser makers can start implementing it and
then we,
> > editor makers, can start using it. This part will already improve the
> > current situation a lot, but it's itself pretty hard as we can see.
Then, if
> > anyone will be still interested, a specification for default browser's
> > actions can be created. It's a huge task and there are a lot of
> > controversial topics like the famous delete/backspace behaviour when
merging
> > blocks and that's why I would not recommend starting these discussions
right
> > now.
> >
> >
> >
> > On Tue, Sep 9, 2014 at 12:59 PM, Frederico Knabben
<f.knabben@cksource.com>
> > wrote:
> >>
> >> On Tuesday, 9 September 2014 at 11:13, Frederico Knabben wrote:
> >>
> >> I don’t think that browsers having time/will for it today is a good
> >> argumentation for not doing it. The specs have a critical and noble
scope,
> >> of serving as reference for the future of the web. We’re talking about
the
> >> future after all.
> >>
> >> Still we may also take in consideration that there are limited
resources
> >> available for working on the specs. Therefore the whole work could be
> >> separated into two *independent* topics:
> >>
> >>  1. Intention events + execCommand.
> >>  2. contenteditable=“minimal”
> >>
> >> “1” should be concluded asap, because it is the foundation for the
success
> >> of “2”. It is also compatible with the current
> contenteditable=“true”, so it
> >> should enable sites/frameworks to fix the current status of things.
> >>
I have to agree with Piotrek, 1 is more important to get done first. It is
very important for mobile and we have real problems with device specific
support across devices. We could refine 1 after 2 is attempted.


> >> “2” is the ideal world. Something that would require much more energy
to
> >> get done right. Still in the beginning, there should be an agreement
on
> >> what’s in and what’s out. Following that, several specs can get
started,
> >> each one defining the default behavior we want for each of the
features we
> >> want “minimal” to have. The first ofc, would be “Selection” (and
“Focus”!).
> >

Rich
> >
> >
> >
> > --
> > Piotrek Koszuliński
> > CKEditor JavaScript Lead Developer
> > --
> > CKSource - http://cksource.com

> > --
> > Follow CKEditor on: Twitter | Facebook | Google+ | LinkedIn