- From: Robin Berjon <robin@w3.org>
- Date: Fri, 06 Jun 2014 15:37:39 +0200
- To: Ben Peters <Ben.Peters@microsoft.com>, Julie Parent <jparent@gmail.com>, Johannes Wilm <johannes@fiduswriter.com>
- CC: "public-webapps@w3.org" <public-webapps@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. 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
Received on Friday, 6 June 2014 13:37:52 UTC