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