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

[Johannes Wilm]

On Mon, Sep 22, 2014 at 3:46 PM, Richard Schwerdtfeger 
wrote:
>
> So, you want to modify contenteditable to "minimum". What will that do to
> existing apps. that are built on it?
>
>
As has been mentioned before, the current (and broken) contenteditable will
stay the way it is, to make sure that nothing breaks for anyone.
contenteditable=minimal or some derivative thereof will come additionally.
With time, when all the frameworks have switched and the usage of
contenteditable is close to zero, I would imagine that browser makers would
likely decide to remove the contenteditable code.

As for Ben's comments -- I think the question he made was to the main
general purpose editors that stand for most of the user created content on
the web. CKeditor is certainly one of them. Others are TinyMCE and possibly
Aloha. And then there are a number of editors created by the browser makers
themselves -- everything from Gmail, Google Docs to Micrsoft's online Word
processor.

Ben was asking whether being able to add items to the right-click context
menu would be something editor creators would like to do. The issue with
this was at least in the past that one can only choose to entirely replace
the context menu, or not at all. If one replaced it, the browser's spell
checker was gone. If one didn't replace it, there was no way to add extra
options. Has this changed at all?

I see for example that CKeditor has chosen to replace the context menu, and
so the spell checker is gone.  Would users of CKeditor not like to have
access to the spell checker? Have you received any feedback on that?

And for those who currently write the specs -- what more information would
you need to go ahead?

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

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

[Richard Schwerdtfeger]

Rich Schwerdtfeger

Ben Peters  wrote on 09/19/2014 03:55:46 PM:

> From: Ben Peters 
> To: Piotr Koszuliński , Frederico
> Knabben 
> Cc: Johannes Wilm , "public-editing-
> t...@w3.org" , Julie Parent
> , "public-indie...@w3.org"  u...@w3.org>, public-webapps 
> 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
>  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

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

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

[Ben Peters]

On Sat, Sep 6, 2014 at 1:54 AM, Johannes Wilm  wrote:
> These both look quite good!
>
> On Example 3 on the commands explainer, I was wondering if it is the idea
> that custom actions only can be triggered by specific key presses, whereas
> for standard events are triggered by "intentions". So say that we listen for
> CTRL+C to trigger our custom intention "checkGrammar" -- but the user's
> browser happens to use a locale where CTRL+C is the common standard for
> bold? Would it not be possible to create a new intention and bind it to
> CTRL+C unless that key combination is occupied already, in which case it's
> CTRL+L, etc.? Could there be a way to get all the key bindings defined for a
> given contenteditable=minimal area and their intentions? (to display in a
> help box, for example)

I think advanced things like custom localization will be out of scope, at least 
initially. This can be done by detecting languages and such. But we should keep 
it in mind.

> Also, would there be a way to bind intentions not just to key clicks but
> also to new items in the right click menu? An editor may want to use the
> internal spell checker, but add a custom thesauruses and a grammar checker
> to the menu. But maybe this is defined somewhere else?

This is something we should keep in mind, but probably won't be in our top 
priorities. If folks think it should be, we should include it though, so please 
give us feedback here.

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

[Ben Peters]

I think what I'm hearing in this conversation about the shape of a new 
contentEditable is really that a simple "minimal" is not going to work. 
Instead, having something like a delimited list will satisfy more people. See 
the bug on GitHub [1] for more details.

https://github.com/w3c/editing-explainer/issues/4 

On Mon, Sep 8, 2014 at 11:55 AM, Johannes Wilm  wrote:
>
>
>
> On Mon, Sep 8, 2014 at 6:05 PM, Frederico Knabben 
> wrote:
>
> 
>  
>>
>> IMHO, the following are the "minimal" features that it should provide:
>>
>> - Selection: UI (e.g. caret), creation (e.g. mouse) and modifications
>> (e.g. arrows)
>> - Focus (probably part of Selection, but it's so hard to make it right
>> that I'm listing it here to not stay forgotten)
>> - Input Text (typing)
>> - Insert New Line
>> - Delete / Backspace
>
>
> If we include deletion/backspace and input text, that will then also mean
> merging of paragraphs (and other nodes) when the caret is at the beginning
> of a second paragraph and the backspace key is being hit? Last I checked
> that was broken for example in Safari/Chrome (converting the HTML inside the
> two merged paragraphs from  into a mix of -tags and
> other outdated things).
>
>
> To me it's fine if inputting text/backspace is being included, as long as
> browser makers believe they will have the time and resources to fix the
> actual text editing part. That to me seems to be the most broken thing about
> the whole thing currently.
>
> If they on the other hand say they have no time for any of this (as not
> having fixed bugs in this area for some years might indicate) I would be OK
> with them leaving the input/deletion/undo history part out.
>
> --
> Johannes Wilm
> Fidus Writer
> http://www.fiduswriter.org

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

[Ben Peters]

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  
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”
>
>
> 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 
> 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.
>>
>> “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”!).
>
>
>
>
> --
> Piotrek Koszuliński
> CKEditor JavaScript Lead Developer
> --
> CKSource - http://cksource.com
> --
> Follow CKEditor on: Twitter | Facebook | Google+ | LinkedIn

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

[Frederico Knabben]

On Thursday, 11 September 2014 at 17:38, Ryosuke Niwa wrote:

>  
> On Sep 9, 2014, at 6:31 AM, Johannes Wilm  (mailto:johan...@fiduswriter.org)> wrote:
> > Absolutely. if this division means we can get into a saner place faster 
> > (and with a higher likelihood that it will actually happen) then I am all 
> > for it.
> >  
> > Of course the long-term future of the web should be taken into 
> > consideration as well, and as I understand it, this could be part of the 
> > second part then.
> >  
> > On Tue, Sep 9, 2014 at 1:28 PM, Piotr Koszuliński 
> > mailto:p.koszulin...@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”
> > >  
> > > 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.
>  
> Could you clarify what use cases could be addressed by implementing 1?
>  
> Since I consider the lack of concrete use cases to be one of the reasons the 
> last few iterations/attempts to implement something like these have failed, I 
> would really like to have a list of concrete use cases that are to be 
> addressed by each specification listed above.
>  
> - R. Niwa
“1” is the basis for being able to replace browser’s (currently broken) default 
behavior for user actions. It would guarantee that all behavior can be 
preventDefault()ed and also provide additional information about the user 
intentions so actions can be better understood, paired with a more accurate 
behavior.  

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

[Ryosuke Niwa]

On Sep 9, 2014, at 6:31 AM, Johannes Wilm  wrote:

> Absolutely. if this division means we can get into a saner place faster (and 
> with a higher likelihood that it will actually happen) then I am all for it.
> 
> Of course the long-term future of the web should be taken into consideration 
> as well, and as I understand it, this could be part of the second part then.
> 
> On Tue, Sep 9, 2014 at 1:28 PM, Piotr Koszuliński 
>  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”
> 
> 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.

Could you clarify what use cases could be addressed by implementing 1?

Since I consider the lack of concrete use cases to be one of the reasons the 
last few iterations/attempts to implement something like these have failed, I 
would really like to have a list of concrete use cases that are to be addressed 
by each specification listed above.

- R. Niwa

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

[Johannes Wilm]

Absolutely. if this division means we can get into a saner place faster
(and with a higher likelihood that it will actually happen) then I am all
for it.

Of course the long-term future of the web should be taken into
consideration as well, and as I understand it, this could be part of the
second part then.




On Tue, Sep 9, 2014 at 1:28 PM, Piotr Koszuliński <
p.koszulin...@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”
>
>
> 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  > 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.
>>
>> “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”!).
>>
>
>
>
> --
> Piotrek Koszuliński
> CKEditor JavaScript Lead Developer
> --
> CKSource - http://cksource.com
> --
> Follow CKEditor on: Twitter  | Facebook
>  | Google+
>  | LinkedIn
> 
>



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

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

[Piotr Koszuliński]

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”


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 
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.
>
> “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”!).
>



-- 
Piotrek Koszuliński
CKEditor JavaScript Lead Developer
--
CKSource - http://cksource.com
--
Follow CKEditor on: Twitter  | Facebook
 | Google+
 | LinkedIn

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

[Frederico Knabben]

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.

“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”!).

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

[Frederico Knabben]

On Monday, 8 September 2014 at 20:55, Johannes Wilm wrote:
> If we include deletion/backspace and input text, that will then also mean 
> merging of paragraphs (and other nodes) when the caret is at the beginning of 
> a second paragraph and the backspace key is being hit?  

Definitely. It’s all about that. About writing specs that will tell how these 
cases should be handled, possibly coupled with ready to use unit tests.  

> To me it's fine if inputting text/backspace is being included, as long as 
> browser makers believe they will have the time and resources to fix the 
> actual text editing part. That to me seems to be the most broken thing about 
> the whole thing currently.
>  
> If they on the other hand say they have no time for any of this (as not 
> having fixed bugs in this area for some years might indicate) I would be OK 
> with them leaving the input/deletion/undo history part out.  
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.  

For instance, we can also predict that, if browser for any reason will not 
implement the specs, a js solution could take place, normalizing the behavior 
of browsers based on the specs. As long as Intention events will take place, 
this would be certainly doable.

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

[Johannes Wilm]

On Mon, Sep 8, 2014 at 6:05 PM, Frederico Knabben 
wrote:




> IMHO, the following are the "minimal" features that it should provide:
>
> - Selection: UI (e.g. caret), creation (e.g. mouse) and modifications
> (e.g. arrows)
> - Focus (probably part of Selection, but it's so hard to make it right
> that I'm listing it here to not stay forgotten)
> - Input Text (typing)
> - Insert New Line
> - Delete / Backspace
>

If we include deletion/backspace and input text, that will then also mean
merging of paragraphs (and other nodes) when the caret is at the beginning
of a second paragraph and the backspace key is being hit? Last I checked
that was broken for example in Safari/Chrome (converting the HTML inside
the two merged paragraphs from  into a mix of -tags
and other outdated things).


To me it's fine if inputting text/backspace is being included, as long as
browser makers believe they will have the time and resources to fix the
actual text editing part. That to me seems to be the most broken thing
about the whole thing currently.

If they on the other hand say they have no time for any of this (as not
having fixed bugs in this area for some years might indicate) I would be OK
with them leaving the input/deletion/undo history part out.

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

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

[Frederico Knabben]

Pretty good docs, Ben.   

I have comments mostly about Issue 2 
(http://w3c.github.io/editing-explainer/#h_issue_2).  

As long as actions are well documented, browsers can provide defaults that will 
fit 90% of the *good quality* content creation requirements out there. 
Additionally just selection is not enough to make content editable, so 
contenteditable=“minimal” would have no sense for the eyes of those not 
participating in this group.

IMHO, the following are the “minimal” features that it should provide:

- Selection: UI (e.g. caret), creation (e.g. mouse) and modifications (e.g. 
arrows)
- Focus (probably part of Selection, but it’s so hard to make it right that I’m 
listing it here to not stay forgotten)
- Input Text (typing)
- Insert New Line
- Delete / Backspace
- Clipboard / DnD
- Undo / Redo

All the above should be paired with the proper Intention events so 
preventDefault and customizations can happen.

Once we agree on what contenteditable=“minimal” should do, the next step would 
be writing specs for each of the above points, in very deep details, including 
all possible patterns and cases (hopefully unit tests). This is to help 
browsers’ adoption, easier implementation and guaranteeing a common behavior 
everywhere, which would require less customizations to happen.

The goal here is fixing editing, not disabling it altogether. Otherwise Issue 5 
(http://w3c.github.io/editing-explainer/#h_issue_5) makes total sense and 
editing will, by default, stay broken.

--
Frederico Knabben
CKEditor Project Lead and CKSource Owner
--
CKSource - http://cksource.com
--
Follow us 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)


On Friday, 5 September 2014 at 23:04, Ben Peters wrote:

> There is now an Editing Explainer [1] and a User Intentions Explainer [2], 
> which should help scope the problems and help us drive forward on both areas. 
> I haven’t done much to fine tune them yet, but please let me know if you have 
> feedback on this split from the initial Commands Explainer document. Thanks!
>   
> [1] http://w3c.github.io/editing-explainer/
> [2] http://w3c.github.io/editing-explainer/commands-explainer.html
>  
> On Mon, Aug 11, 2014 at 5:23 PM, Ben Peters  (mailto:ben.pet...@microsoft.com)> wrote:
> >
> > I agree with this. We should have a single 'shape' for these events and 
> > shared terminology.
> >
> > I think trying to solve all of the problems in one complete spec would be 
> > too complex,  but if we use an Intentions Explainer to divide the problem 
> > into manageable pieces, we can continue on our trajectory of creating these 
> > events for Selection, Clipboard, Drag and Drop, Input (aka Editing), and 
> > perhaps other user interactions. Are there objections to this approach? If 
> > not, I will begin to adapt the Commands Explainer into a more generic 
> > Intentions Explainer.
> >  

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

[Johannes Wilm]

These both look quite good!

On Example 3 on the commands explainer, I was wondering if it is the idea
that custom actions only can be triggered by specific key presses, whereas
for standard events are triggered by "intentions". So say that we listen
for CTRL+C to trigger our custom intention "checkGrammar" -- but the user's
browser happens to use a locale where CTRL+C is the common standard for
bold? Would it not be possible to create a new intention and bind it to
CTRL+C unless that key combination is occupied already, in which case it's
CTRL+L, etc.? Could there be a way to get all the key bindings defined for
a given contenteditable=minimal area and their intentions? (to display in a
help box, for example)

Also, would there be a way to bind intentions not just to key clicks but
also to new items in the right click menu? An editor may want to use the
internal spell checker, but add a custom thesauruses and a grammar checker
to the menu. But maybe this is defined somewhere else?


On Fri, Sep 5, 2014 at 11:04 PM, Ben Peters 
wrote:

>  There is now an Editing Explainer [1] and a User Intentions Explainer
> [2], which should help scope the problems and help us drive forward on both
> areas. I haven't done much to fine tune them yet, but please let me know if
> you have feedback on this split from the initial Commands Explainer
> document. Thanks!
>
>
>
> [1] http://w3c.github.io/editing-explainer/
>
> [2] http://w3c.github.io/editing-explainer/commands-explainer.html
>
> On Mon, Aug 11, 2014 at 5:23 PM, Ben Peters 
> wrote:
> >
> > I agree with this. We should have a single 'shape' for these events and
> shared terminology.
> >
> > I think trying to solve all of the problems in one complete spec would
> be too complex,  but if we use an Intentions Explainer to divide the
> problem into manageable pieces, we can continue on our trajectory of
> creating these events for Selection, Clipboard, Drag and Drop, Input (aka
> Editing), and perhaps other user interactions. Are there objections to this
> approach? If not, I will begin to adapt the Commands Explainer into a more
> generic Intentions Explainer.
> >
>



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

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

[Ben Peters]

There is now an Editing Explainer [1] and a User Intentions Explainer [2], 
which should help scope the problems and help us drive forward on both areas. I 
haven't done much to fine tune them yet, but please let me know if you have 
feedback on this split from the initial Commands Explainer document. Thanks!

[1] http://w3c.github.io/editing-explainer/
[2] http://w3c.github.io/editing-explainer/commands-explainer.html

On Mon, Aug 11, 2014 at 5:23 PM, Ben Peters  wrote:
>
> I agree with this. We should have a single 'shape' for these events and 
> shared terminology.
>
> I think trying to solve all of the problems in one complete spec would be too 
> complex,  but if we use an Intentions Explainer to divide the problem into 
> manageable pieces, we can continue on our trajectory of creating these events 
> for Selection, Clipboard, Drag and Drop, Input (aka Editing), and perhaps 
> other user interactions. Are there objections to this approach? If not, I 
> will begin to adapt the Commands Explainer into a more generic Intentions 
> Explainer.
>

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

[Ben Peters]

I agree with this. We should have a single 'shape' for these events and shared 
terminology. 

I think trying to solve all of the problems in one complete spec would be too 
complex,  but if we use an Intentions Explainer to divide the problem into 
manageable pieces, we can continue on our trajectory of creating these events 
for Selection, Clipboard, Drag and Drop, Input (aka Editing), and perhaps other 
user interactions. Are there objections to this approach? If not, I will begin 
to adapt the Commands Explainer into a more generic Intentions Explainer.

> -Original Message-
> From: Jason White [mailto:ja...@jasonjgw.net]
> Sent: Saturday, August 9, 2014 4:56 PM
> To: public-indie...@w3.org
> Cc: public-editing...@w3.org; public-webapps@w3.org
> Subject: Re: User Intentions Explainer (was: List of Intentions)
> 
> [Cross-posting the comments below per Janina's thoughtful request.]
> 
> I concur with Janina's insightful remark [at the Indie-UI teleconference on
> Thursday] that the "explainer" could evolve into a (potentially cross-group)
> requirements document. This raises several issues.
> 
> 1. Harmonization of terminology. We're already seeing differences between
> the terminology used by WEB Apps in connection with editing and our own
> terms for similar concepts, e.g., "abstract events" and "intentions". Naming
> conventions for events aren't harmonized either.
> 
> 2. Whether there should ultimately be one spec or several, and where the
> division should lie, is obviously up for discussion. Given the progress we've
> made to date, it makes good sense that support for interactive editing could
> reside in its own spec, with its own development schedule. This, after all, is
> work that we anticipated in Indie-UI but postponed.
> 
> 3. If there are two or more specs to be produced in this area, we should
> provide appropriate cross-references (perhaps a non-normative reference in
> each spec to the requirements would be sufficient), so that user agent and
> Web application implementors alike can readily appreciate the relationships
> between the technologies described in the respective documents.
> 
> My main concern at this point is that the designs be consistent and that
> terminology be unified wherever possible.
> 
> 

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

[Jason White]

[Cross-posting the comments below per Janina's thoughtful request.]

I concur with Janina's insightful remark [at the Indie-UI teleconference on
Thursday] that the "explainer" could evolve into a (potentially cross-group)
requirements document. This raises several issues.

1. Harmonization of terminology. We're already seeing differences between the
terminology used by WEB Apps in connection with editing and our own terms for
similar concepts, e.g., "abstract events" and "intentions". Naming conventions
for events aren't harmonized either.

2. Whether there should ultimately be one spec or several, and where the
division should lie, is obviously up for discussion. Given the progress we've
made to date, it makes good sense that support for interactive editing could
reside in its own spec, with its own development schedule. This, after all, is
work that we anticipated in Indie-UI but postponed.

3. If there are two or more specs to be produced in this area, we should
provide appropriate cross-references (perhaps a non-normative reference in
each spec to the requirements would be sufficient), so that user agent and Web
application implementors alike can readily appreciate the relationships
between the technologies described in the respective documents.

My main concern at this point is that the designs be consistent and
that terminology be unified wherever possible.

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

[James Craig]

From: Julie Parent 
>  
>> This is a great list, and I agree it is the right starting point.
>> 
>> On Mon, Jul 21, 2014 at 6:12 PM, Ben Peters  wrote:
>>> * Activate / Invoke 
>>> 
>>>  * Expand
>>>  * Collapse
>>>  * Dismiss
>>>  * Media next/previous/start/stop/pause
>>>  * Rotate
>>>  * Zoom
>>>  * Value change
>> 
>> Is this the set from indie-ui?  I think we should make a decision if we are 
>> trying to cover these cases or not, as they do not make sense in the context 
>> of rich text editing and might be out of scope.

Sorry Julie, I didn't see your original email. Perhaps you removed the 
cross-posted lists? I'm on both IndieUI and WebApps, but didn't see it come 
through.

With the possible exception of the media events, all of the above events make 
sense in the context of editing. For example, in Word or Pages:

1. You can "expand" or "collapse" sections of a document.
2. You can "zoom" in on the document view. 
3. You can "rotate" an embedded photo or chart. 
4. You can "scale" a variety of elements by focusing on a corner handle (e.g. 
drag handle) and nudging it with arrow keys, or a mouse, or by touch. These can 
be modified in some apps. For example, option+arrow moves this handle by a 
smaller amount than unmodified arrow keys. This is a use case for either 
"scale" on the main object, or "value change" on the corner control.


>> It would help to have a list of arguments for/against merging with indie-ui?

I don't know if the arguments need to be about merging working groups. I don't 
care where the work happens, as long as it happens. I'd be fine with disbanding 
IndieUI if WebApps is ready to take up the work, but text editing is only one 
piece of it. IMO, it doesn't make sense to design one API for text editing, and 
another API for graphic manipulation, and another for form manipulation. 

One of the use cases that was deferred from the 1.0 version of IndieUI was to 
"mark" for some later action. For example, in a text editor, click in one spot, 
then shift+click in another to select a range of text. The next action (such as 
Delete) applies to the selection. On most desktop platforms, this works with 
text selection, but also on collections like table views: click then 
shift+click to select multiple songs in a music player, or multiple messages in 
an email inbox. 

INDIEUI-ACTION-25: Add markRequest with variant properties indicating 
"fromLast" (like Shift+click or select range from last mark) and "retainMarks" 
(like Mac Cmd+click or Win Ctrl+click meaning select in addition to)

https://www.w3.org/WAI/IndieUI/track/actions/25

Hopefully these examples demonstrate how overlapping the work is. It'd be 
tempting to limit the scope to text editing, but I feel that'd ultimately be 
short-sighted.

James


-- 
Indifference towards people and the reality in 
which they live is actually the one and only 
cardinal sin in design. — Dieter Rams

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

[Cynthia Shelly]

This is a really solid list.  Thank you for pulling it together, so we can 
start towards a harmonized set of user events.

From: Ben Peters [mailto:ben.pet...@microsoft.com]
Sent: Monday, August 4, 2014 7:28 PM
To: public-editing...@w3.org; Julie Parent; public-indie...@w3.org; 
public-webapps
Subject: User Intentions Explainer (was: List of Intentions)


Cross-posted​: Editing TF, IndieUI TF, WebApps WG


In order to solve the broad issue of User Intentions, we have compiled below a 
list of User Intentions derived from all of the sources of intention-style 
events that I am aware of. I agree with Julie that some of the events below are 
not in scope for Editing at this time. However, they are in scope for IndieUI, 
and I think that we have an important opportunity here to bring all concepts of 
"Intentions" together in a single explainer document so that 1) web developers 
can have a coherent picture of how to understand User Intentions and 2) the 
specs that concern User Intentions do not overlap. To that end, I propose that 
we create a new User Intentions Explainer document, borrowing from the work of 
the Editing Explainer and IndieUI to give an overview of how all of the 
following Intention Events work together in a high-level non-normative form:

Clipboard API
HTML5 Drag and Drop
Selection API (beforeSelectionChange)
DOM Events (beforeInput)
IndieUI

Each of these specs solves some aspect of User Intentions, and they should be 
coherent. For instance, we need to solve how beforeInput does not overlap 
Clipboard and DnD, and consider moving some parts of IndieUI that apply to 
input (undo/redo) to beforeInput.

Further, I propose that we fine-tune the Editing Explainer, making it clear 
that there are two problems we're trying to solve in that space- Editing 
Intentions and Extensible Web Editing. From there we can begin to create 
normative specs for solving these two Editing problems.

The end result of this would be a high-level explainer for all known User 
Intention specs, and a high-level explainer for Editing. Then we can solve each 
individual problem more granularly while maintaining coherence. Thoughts?

From: Julie Parent mailto:jpar...@google.com>>
>
> This is a great list, and I agree it is the right starting point.
>
>
> On Mon, Jul 21, 2014 at 6:12 PM, Ben Peters 
> mailto:ben.pet...@microsoft.com>> wrote:
>>
>> We now have a good list of use cases on the Explainer[1]. I believe the next 
>> step is to come up with the Intentions that we need to allow sites and 
>> frameworks to respond to. After that, we can determine which current or new 
>> spec each Intention is covered by. Please let me know what you think of this 
>> list and if you agree it covers our use cases. The last several are borrowed 
>> from IndieUI[2], which we could use to cover those cases if we believe that 
>> is best.
>>
>> * Focus/place caret
>> * Move caret
>> * Start selection (eg mouse down to select)
>> * Update selection (eg mouse move during selection)
>> * Finish selection (eg mouse up after selecting)
>> * Modify selection (extend selection after it's finished. Might be covered 
>> by update/finish)
>> * Insert text
>> * Insert content / insert HTML
>> * Delete content
>> * Delete forward
>> * Delete backward
>> * Insert newline
>
>
> Do we need newline as a special case? Wouldn't this be covered by insert 
> text/content/HTML?
>
>>
>> * Undo
>> * Redo
>> * Paste
>> * Copy
>> * Cut
>> * Drag start/over/stop
>> * Drop
>> * Scroll/pan
>
>
>>
>> * Activate / Invoke
>>
>> * Expand
>> * Collapse
>> * Dismiss
>> * Media next/previous/start/stop/pause
>> * Rotate
>> * Zoom
>> * Value change
>
>
> Is this the set from indie-ui?  I think we should make a decision if we are 
> trying to cover these cases or not, as they do not make sense in the context 
> of rich text editing and might be out of scope.  It would help to have a list 
> of arguments for/against merging with indie-ui?
>
>>
>>
>> Ben
>> [1] http://w3c.github.io/editing-explainer/commands-explainer.html
>> [2] http://www.w3.org/TR/indie-ui-events/

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

[Ryosuke Niwa]

On Aug 4, 2014, at 7:28 PM, Ben Peters  wrote:

> Cross-posted​: Editing TF, IndieUI TF, WebApps WG
> 
> In order to solve the broad issue of User Intentions, we have compiled below 
> a list of User Intentions derived from all of the sources of intention-style 
> events that I am aware of. I agree with Julie that some of the events below 
> are not in scope for Editing at this time. However, they are in scope for 
> IndieUI, and I think that we have an important opportunity here to bring all 
> concepts of "Intentions" together in a single explainer document so that 1) 
> web developers can have a coherent picture of how to understand User 
> Intentions and 2) the specs that concern User Intentions do not overlap. To 
> that end, I propose that we create a new User Intentions Explainer document, 
> borrowing from the work of the Editing Explainer and IndieUI to give an 
> overview of how all of the following Intention Events work together in a 
> high-level non-normative form:

Looking at the broader perspective is a great idea since many user actions such 
as copying and pasting are not specific text editable regions.

> Clipboard API
> HTML5 Drag and Drop
> Selection API (beforeSelectionChange)
> DOM Events (beforeInput)
> IndieUI
> 
> Each of these specs solves some aspect of User Intentions, and they should be 
> coherent. For instance, we need to solve how beforeInput does not overlap 
> Clipboard and DnD, and consider moving some parts of IndieUI that apply to 
> input (undo/redo) to beforeInput.

Indeed.

> Further, I propose that we fine-tune the Editing Explainer, making it clear 
> that there are two problems we're trying to solve in that space- Editing 
> Intentions and Extensible Web Editing. From there we can begin to create 
> normative specs for solving these two Editing problems.

I don’t think we need to necessarily scope specifically for editing per se.  
There is a broader set of user actions that need to manually detected by the 
web apps at the moment, and it would be nice to create event-based API that 
could be extended for other applications such as drawing apps and various UI 
components such as a color palette, etc…

> The end result of this would be a high-level explainer for all known User 
> Intention specs, and a high-level explainer for Editing. Then we can solve 
> each individual problem more granularly while maintaining coherence. Thoughts?

Perhaps we even want to look at the list of use case in 
http://www.w3.org/TR/indie-ui-requirements/ and come up with a single coherent 
API.  It would be really nice if we added the “intention” events as the 
foundation for all UI interactions and built extensible editing API on top of 
it.

- R. Niwa

User Intentions Explainer (was: List of Intentions)

[Ben Peters]

Cross-posted?: Editing TF, IndieUI TF, WebApps WG


In order to solve the broad issue of User Intentions, we have compiled below a 
list of User Intentions derived from all of the sources of intention-style 
events that I am aware of. I agree with Julie that some of the events below are 
not in scope for Editing at this time. However, they are in scope for IndieUI, 
and I think that we have an important opportunity here to bring all concepts of 
"Intentions" together in a single explainer document so that 1) web developers 
can have a coherent picture of how to understand User Intentions and 2) the 
specs that concern User Intentions do not overlap. To that end, I propose that 
we create a new User Intentions Explainer document, borrowing from the work of 
the Editing Explainer and IndieUI to give an overview of how all of the 
following Intention Events work together in a high-level non-normative form:

Clipboard API
HTML5 Drag and Drop
Selection API (beforeSelectionChange)
DOM Events (beforeInput)
IndieUI

Each of these specs solves some aspect of User Intentions, and they should be 
coherent. For instance, we need to solve how beforeInput does not overlap 
Clipboard and DnD, and consider moving some parts of IndieUI that apply to 
input (undo/redo) to beforeInput.

Further, I propose that we fine-tune the Editing Explainer, making it clear 
that there are two problems we're trying to solve in that space- Editing 
Intentions and Extensible Web Editing. From there we can begin to create 
normative specs for solving these two Editing problems.

The end result of this would be a high-level explainer for all known User 
Intention specs, and a high-level explainer for Editing. Then we can solve each 
individual problem more granularly while maintaining coherence. Thoughts?

From: Julie Parent 
>
> This is a great list, and I agree it is the right starting point.
>
>
> On Mon, Jul 21, 2014 at 6:12 PM, Ben Peters  wrote:
>>
>> We now have a good list of use cases on the Explainer[1]. I believe the next 
>> step is to come up with the Intentions that we need to allow sites and 
>> frameworks to respond to. After that, we can determine which current or new 
>> spec each Intention is covered by. Please let me know what you think of this 
>> list and if you agree it covers our use cases. The last several are borrowed 
>> from IndieUI[2], which we could use to cover those cases if we believe that 
>> is best.
>>
>> * Focus/place caret
>> * Move caret
>> * Start selection (eg mouse down to select)
>> * Update selection (eg mouse move during selection)
>> * Finish selection (eg mouse up after selecting)
>> * Modify selection (extend selection after it's finished. Might be covered 
>> by update/finish)
>> * Insert text
>> * Insert content / insert HTML
>> * Delete content
>> * Delete forward
>> * Delete backward
>> * Insert newline
>
>
> Do we need newline as a special case? Wouldn't this be covered by insert 
> text/content/HTML?
>
>>
>> * Undo
>> * Redo
>> * Paste
>> * Copy
>> * Cut
>> * Drag start/over/stop
>> * Drop
>> * Scroll/pan
>
>
>>
>> * Activate / Invoke
>>
>> * Expand
>> * Collapse
>> * Dismiss
>> * Media next/previous/start/stop/pause
>> * Rotate
>> * Zoom
>> * Value change
>
>
> Is this the set from indie-ui?  I think we should make a decision if we are 
> trying to cover these cases or not, as they do not make sense in the context 
> of rich text editing and might be out of scope.  It would help to have a list 
> of arguments for/against merging with indie-ui?
>
>>
>>
>> Ben
>> [1] http://w3c.github.io/editing-explainer/commands-explainer.html
>> [2] http://www.w3.org/TR/indie-ui-events/