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

2014-09-22 Thread Richard Schwerdtfeger



Rich Schwerdtfeger

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

 From: Ben Peters ben.pet...@microsoft.com
 To: Piotr Koszuliński p.koszulin...@cksource.com, Frederico
 Knabben f.knab...@cksource.com
 Cc: Johannes Wilm johan...@fiduswriter.org, public-editing-
 t...@w3.org public-editing...@w3.org, Julie Parent
 jpar...@gmail.com, public-indie...@w3.org public-indie-
 u...@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.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”
 
 
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.knab...@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

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

2014-09-22 Thread Johannes Wilm
On Mon, Sep 22, 2014 at 3:46 PM, Richard Schwerdtfeger sch...@us.ibm.com
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)

2014-09-19 Thread 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 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 f.knab...@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.

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

2014-09-19 Thread 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 johan...@fiduswriter.org wrote:



 On Mon, Sep 8, 2014 at 6:05 PM, Frederico Knabben f.knab...@cksource.com
 wrote:

 snip
  

 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 span style= into a mix of font-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)

2014-09-19 Thread Ben Peters


On Sat, Sep 6, 2014 at 1:54 AM, Johannes Wilm johan...@fiduswriter.org 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)

2014-09-12 Thread Frederico Knabben


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

  
 On Sep 9, 2014, at 6:31 AM, Johannes Wilm johan...@fiduswriter.org 
 (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 
  p.koszulin...@cksource.com (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)

2014-09-11 Thread Ryosuke Niwa

On Sep 9, 2014, at 6:31 AM, Johannes Wilm 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 
 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



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

2014-09-09 Thread 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)

2014-09-09 Thread 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)

2014-09-09 Thread 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 f.knab...@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.

 “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 http://twitter.com/ckeditor | Facebook
http://www.facebook.com/ckeditor | Google+
https://plus.google.com/107736718646302128806 | LinkedIn
http://www.linkedin.com/company/cksource


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

2014-09-09 Thread 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 f.knab...@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.

 “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 http://twitter.com/ckeditor | Facebook
 http://www.facebook.com/ckeditor | Google+
 https://plus.google.com/107736718646302128806 | LinkedIn
 http://www.linkedin.com/company/cksource




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


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

2014-09-08 Thread 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 ben.pet...@microsoft.com 
 (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)

2014-09-08 Thread Johannes Wilm
On Mon, Sep 8, 2014 at 6:05 PM, Frederico Knabben f.knab...@cksource.com
wrote:

snip


 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 span style= into a mix of font-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)

2014-09-06 Thread 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 ben.pet...@microsoft.com
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 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.
 




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


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

2014-09-05 Thread 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 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)

2014-08-11 Thread 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)

2014-08-09 Thread 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)

2014-08-08 Thread 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 jpar...@google.commailto: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 
 ben.pet...@microsoft.commailto: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)

2014-08-08 Thread James Craig
From: Julie Parent 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 ben.pet...@microsoft.com 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)

2014-08-04 Thread Ryosuke Niwa
On Aug 4, 2014, at 7:28 PM, Ben Peters ben.pet...@microsoft.com 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