RE: User Intentions Explainer (was: List of Intentions)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
[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)
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)
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
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.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: 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)
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
