RE: CommandEvent for user intentions
> From: Robin Berjon [mailto:ro...@w3.org] > > On 21/05/2014 20:51 , Ben Peters wrote: > >>> I’m not sure an extra event type is necessary here though: why not > >>> use beforeinput for the input events, and selectionchange for > >>> selection events? Ryosuke’s selection spec currently has a > >>> placeholder for selectionchange, and seems like the right place and > >>> timing to work this in? > > My current thought is that Selection events should be used for > > selection, and CommandEvent for things that would be in a toolbar or > > context menu. I think the design should make it easy to create and > > style toolbars based on the available commands and their state. > > Right. I agree with the architecture you described at the beginning of the > thread, but I was a bit worried about your usage of a "select-all" > command event as an example. You're right, that was confusing. We have since updating our thoughts to use BeforeSelectionChange for this. > There are many, many ways of affecting selection that vary across tools and > locales, and representing all of them would IMHO be painful. > > Do you ever need a select-all event? I would think that a selection change > event that happens to give you a selection object containing everything > might suffice? (Which sort of seems to be what you're saying here — hence > checking where you stand.) I think we may want to give both the user intent (select all) and the browsers interpretation of that intent (the range representing the expected selection).
Re: CommandEvent for user intentions
On 21/05/2014 20:51 , Ben Peters wrote: I’m not sure an extra event type is necessary here though: why not use beforeinput for the input events, and selectionchange for selection events? Ryosuke’s selection spec currently has a placeholder for selectionchange, and seems like the right place and timing to work this in? My current thought is that Selection events should be used for selection, and CommandEvent for things that would be in a toolbar or context menu. I think the design should make it easy to create and style toolbars based on the available commands and their state. Right. I agree with the architecture you described at the beginning of the thread, but I was a bit worried about your usage of a "select-all" command event as an example. There are many, many ways of affecting selection that vary across tools and locales, and representing all of them would IMHO be painful. Do you ever need a select-all event? I would think that a selection change event that happens to give you a selection object containing everything might suffice? (Which sort of seems to be what you're saying here — hence checking where you stand.) -- Robin Berjon - http://berjon.com/ - @robinberjon
[admin] Reminder of Patent Policy for Non-member Contributions [Was: Fwd: Re: CommandEvent for user intentions]
Hi Piotr, All, This is a reminder the W3C's Patent Policy has a goal of assuring W3C Recommendations can be implemented Royalty-Free and this requires all spec contributions include a commitment to that policy. This topic was last discussed in September 2013 and I encourage all Contributors and Editors to read it in its entirety. Here is a short excerpt: [[ <http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0654.html> ... All Participants in a given Working Group have made a commitment to the W3C Patent Policy (in particular, the provisions regarding licensing obligations), but only for the Recommendations of that particular Working Group. In general, other parties have not made the same commitment for those same deliverables, although they MAY make this commitment if they wish. Similarly, W3C may request that they make such a commitment (see instructions for licensing commitments from non-W3C Members). This means that the Working Group should consider very carefully any contribution from a non-Participant before including it in a document intended to become a W3C Recommendation. ]] Piotr, All - before a proposal/contribution from you - or any other non-WG member - can be included in a specification, we must have a proper patent commitment from your organization via <http://www.w3.org/2004/01/pp-impl/42538/nmlc>. I will followup separately with you re how you can make such a commitment. Editors - please do _not_ include any contributions from non-WG unless you are sure they have made a patent commitment. In the event you are unsure, please notify me. For a list of WebApps' Members and participants see <http://www.w3.org/2004/01/pp-impl/42538/status>. -Thanks, AB Original Message ---- Subject: Re: CommandEvent for user intentions Resent-Date:Thu, 22 May 2014 15:24:09 + Resent-From:public-webapps@w3.org Date: Thu, 22 May 2014 13:02:39 +0200 From: Piotr Koszuliński To: Ben Peters CC: Julie Parent , Johannes Wilm , "public-webapps@w3.org" I wrote a longer reply in the contentEditable=minimal thread, which touches some aspects of command events. Actually, before some stable point about cE=minimal is reached I feel that it may be hard to design command events in a way that both are interoperable. Command events should be an extension to cE=minimal making it possible to create advanced solutions on top of it. Therefore, it may be beneficial to discuss both of them in one thread. But for now, here are some additional thoughts which I haven't included in the email about cE=minimal. 1. It should be possible to modify selection and DOM in a command event listener, but leave the action to the browser. Browser should perform the action on the updated selection and DOM. Example - I want to transform "* " to a list when user types additional character. So I would listen to keyboard event, check if two previous characters are "* ", replace them with a list and place selection inside . But I want browser to perform character insertion so I don't have to handle undo manager, scrolling to show caret, etc. There are of course other ways to achieve the same, but this seems to be the cleanest. 2. It's not totally necessary, but it would be nice if command event would also carry an information about its future result. For example command fired for up-arrow key could carry a range with the proposed position of caret. So if I don't agree with browser implementation, because for example it enters a non-editable region, I can check that and handle this specific case by myself. Since there's no easy JavaScript solution for handling up/down arrow keys such information would allow us to focus only on these specific behaviours we don't like. -- Piotrek Koszuliński CKEditor JavaScript Lead Developer
RE: CommandEvent for user intentions
On Thu, May 22, 2014 at 4:02 AM, Piotr Koszuliński wrote: > > I wrote a longer reply in the contentEditable=minimal thread, which touches > some aspects of command events. Actually, before some stable point about > cE=minimal is reached I feel that it may be hard to design command events in > a way that both are interoperable. Command events should be an extension to > cE=minimal making it possible to create advanced solutions on top of it. > Therefore, it may be beneficial to discuss both of them in one thread. > > But for now, here are some additional thoughts which I haven't included in > the email about cE=minimal. > > 1. It should be possible to modify selection and DOM in a command event > listener, but leave the action to the browser. Browser should perform the > action on the updated selection and DOM. Example - I want to transform "* " > to a list when user types additional character. So I would listen to keyboard > event, check if two previous characters are "* ", replace them with a list > and place selection inside . But I want browser to perform character > insertion so I don't have to handle undo manager, scrolling to show caret, > etc. There are of course other ways to achieve the same, but this seems to be > the cleanest. Yes this is an important concept. In CommandEvent, you should be able to modify the behavior and then not call preventDefault. This will allow the browser to perform the action with new data. > 2. It's not totally necessary, but it would be nice if command event would > also carry an information about its future result. For example command fired > for up-arrow key could carry a range with the proposed position of caret. So > if I don't agree with browser implementation, because for example it enters a > non-editable region, I can check that and handle this specific case by > myself. Since there's no easy JavaScript solution for handling up/down arrow > keys such information would allow us to focus only on these specific > behaviours we don't like. Great idea! I'll include this in my draft Explainer doc, which is coming later today.
Re: CommandEvent for user intentions
I wrote a longer reply in the contentEditable=minimal thread, which touches some aspects of command events. Actually, before some stable point about cE=minimal is reached I feel that it may be hard to design command events in a way that both are interoperable. Command events should be an extension to cE=minimal making it possible to create advanced solutions on top of it. Therefore, it may be beneficial to discuss both of them in one thread. But for now, here are some additional thoughts which I haven't included in the email about cE=minimal. 1. It should be possible to modify selection and DOM in a command event listener, but leave the action to the browser. Browser should perform the action on the updated selection and DOM. Example - I want to transform "* " to a list when user types additional character. So I would listen to keyboard event, check if two previous characters are "* ", replace them with a list and place selection inside . But I want browser to perform character insertion so I don't have to handle undo manager, scrolling to show caret, etc. There are of course other ways to achieve the same, but this seems to be the cleanest. 2. It's not totally necessary, but it would be nice if command event would also carry an information about its future result. For example command fired for up-arrow key could carry a range with the proposed position of caret. So if I don't agree with browser implementation, because for example it enters a non-editable region, I can check that and handle this specific case by myself. Since there's no easy JavaScript solution for handling up/down arrow keys such information would allow us to focus only on these specific behaviours we don't like. -- Piotrek Koszuliński CKEditor JavaScript Lead Developer
RE: CommandEvent for user intentions
That is a great article! “A good WYSIWYG editor of arbitrary HTML is just as impossible as the halting problem is impossible... we have to treat it as an editor platform and API, rather than as a standalone component that tries to do everything itself.” Let’s build a platform! From: Julie Parent [mailto:jpar...@gmail.com] Have you seen the recent post about the rich text editor that Medium uses? It is a somewhat cheeky essay, including a mathematical proof, about how contentEditable is broken. The conclusion is that in order to move forward, we need to treat contentEditable as an API, rather than as a standalone component that tries to do everything itself. It discusses the idea of an "edit intent API", which is very in line with this proposal for CommandEvents. https://medium.com/medium-eng/122d8a40e480 On Wed, May 21, 2014 at 11:51 AM, Ben Peters mailto:ben.pet...@microsoft.com>> wrote: Great to hear! I’m working on an explainer document that will be more descriptive than the short wiki docs I wrote a couple weeks ago. My thoughts on your questions should be made clearer there. I’ll update this thread by the end of the week with more details, and my initial thoughts are below.
Re: CommandEvent for user intentions
Have you seen the recent post about the rich text editor that Medium uses? It is a somewhat cheeky essay, including a mathematical proof, about how contentEditable is broken. The conclusion is that in order to move forward, we need to treat contentEditable as an API, rather than as a standalone component that tries to do everything itself. It discusses the idea of an "edit intent API", which is very in line with this proposal for CommandEvents. https://medium.com/medium-eng/122d8a40e480 On Wed, May 21, 2014 at 11:51 AM, Ben Peters wrote: > Great to hear! I’m working on an explainer document that will be more > descriptive than the short wiki docs I wrote a couple weeks ago. My > thoughts on your questions should be made clearer there. I’ll update this > thread by the end of the week with more details, and my initial thoughts > are below. > > > I strongly agree that something like CommandEvents is necessary: a web > developer should be able to respond to the user’s intent, aka “selectAll”, > rather than enumerating, listening to, and responding to each and every > platform specific way that the intention to selectAll can be communicated. > > > How encompassing do you envision CommandEvents? Would it only cover > well known keyboard shortcuts and actions like those currently used by > execCommand? > > I see this as being more than just well-known keyboard shortcuts. I would > like web developers to be able to extend it for their own purposes. > > > What about taking this further and providing better events in two > distinct areas: those involving selections (intents like selectAll, but > also selection modifications like caret movement by keyboard or gestures, > selection changes, etc) and those involving input (including > paste/drop/cut/formatting, but also basic text insertion via > keyboard/voice/etc). > > This is a great idea! I'll include it in my spec. > > > I’m not sure an extra event type is necessary here though: why not use > beforeinput for the input events, and selectionchange for selection events? > Ryosuke’s selection spec currently has a placeholder for selectionchange, > and seems like the right place and timing to work this in? > > My current thought is that Selection events should be used for selection, > and CommandEvent for things that would be in a toolbar or context menu. I > think the design should make it easy to create and style toolbars based on > the available commands and their state. Input events don't cover everything > that would be in a toolbar, and they fire for things that already have > events for user intentions (like Clipboard Events). >
RE: CommandEvent for user intentions
Great to hear! I’m working on an explainer document that will be more descriptive than the short wiki docs I wrote a couple weeks ago. My thoughts on your questions should be made clearer there. I’ll update this thread by the end of the week with more details, and my initial thoughts are below. > I strongly agree that something like CommandEvents is necessary: a web > developer should be able to respond to the user’s intent, aka “selectAll”, > rather than enumerating, listening to, and responding to each and every > platform specific way that the intention to selectAll can be communicated. > How encompassing do you envision CommandEvents? Would it only cover well > known keyboard shortcuts and actions like those currently used by execCommand? I see this as being more than just well-known keyboard shortcuts. I would like web developers to be able to extend it for their own purposes. > What about taking this further and providing better events in two distinct > areas: those involving selections (intents like selectAll, but also selection > modifications like caret movement by keyboard or gestures, selection changes, > etc) and those involving input (including paste/drop/cut/formatting, but also > basic text insertion via keyboard/voice/etc). This is a great idea! I'll include it in my spec. > I’m not sure an extra event type is necessary here though: why not use > beforeinput for the input events, and selectionchange for selection events? > Ryosuke’s selection spec currently has a placeholder for selectionchange, and > seems like the right place and timing to work this in? My current thought is that Selection events should be used for selection, and CommandEvent for things that would be in a toolbar or context menu. I think the design should make it easy to create and style toolbars based on the available commands and their state. Input events don't cover everything that would be in a toolbar, and they fire for things that already have events for user intentions (like Clipboard Events).
