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