RE: CommandEvent for user intentions

> From: Robin Berjon [mailto:robin@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).

Received on Friday, 6 June 2014 19:37:11 UTC