Re: IndieUI brainstorming

On Tue, Jan 8, 2013 at 6:38 PM, James Craig <jcraig@apple.com> wrote:

> > For a value change request on a slider or scroll bar, are
> "increment_max" and "decrement_max" supposed to be the same as "skip to
> start" and "skip to end", for example what might happen if you press Home
> or End? Also, I think it'd be useful to explicitly have equivalents to
> Page-Up and Page-Down - it often makes sense to scroll by one "page".
>
> I was hoping to clarify that with the informative keyboard example here,
> that includes PageUp/PageDown,
>
> https://dvcs.w3.org/hg/IndieUI/raw-file/tip/src/indie-ui-events.html#UIValueChangeRequestEvents
>
> PageUp would most likely send INCREMENT_LARGE.
> PageDown would most likely send DECREMENT_LARGE.
>

I'm okay with large == page. I still think we need a "skip to start" and
"skip to end", corresponding to Home/End.


> > What if you have a listbox, grid, or tree? It's not clear to me which UI
> Request events you'd use to manipulate those controls. Value change doesn't
> really fit, and "Move" specifically talks about deltas in CSS coordinates,
> not discrete items. I'd like to see, at a minimum: next/previous and
> first/last for a list or tree, and up/down/left/right, and
> row-start/row-end/col-start/col-end for a grid.
>
> I think those will more covered by the focus change events (for non-linear
> navigation) and markrequest for selection non covered by the default
> activation event, but neither of these are in the spec yet. We do have a
> few actions tracking them though.
>
> https://www.w3.org/WAI/IndieUI/track/actions/13
> https://www.w3.org/WAI/IndieUI/track/actions/14
> https://www.w3.org/WAI/IndieUI/track/actions/15
> https://www.w3.org/WAI/IndieUI/track/actions/25


Great. Same as above, the only ones I see missing are actions to skip to
the first/last element.

> UI Request events like next/previous and first/last might also apply when
> you have a pop-up menu (combobox), radio button group, or tablist.
> >
> > Finally, what if you have an editable text widget? The web is now full
> of text editors, code editors, word processors, and terminal emulators. Web
> authors currently have to listen for platform-specific keystrokes or
> gestures in order to implement things like moving by word or extending the
> selection by character, word, or line. How about an action representing a
> text cursor change request where the fields could indicate movement by
> character, word, or line - and a boolean field could indicate whether the
> cursor should move or the selection should be extended?
>
> I think the custom RTE view problem is complex enough that it may require
> an API that is outside the scope of IndieUI 1.0. We currently have a custom
> text editing issue open for ARIA 2.0, but we haven't made much progress on
> it yet.


If it ends up being too much beyond IndieUI 1.0, that's fine - but would
you have any objections to considering it and discussing it in this group,
with the idea that if it grows too complicated or we can't reach a
consensus, we won't let it hold up the spec and we'll just leave it out
until we're happy with it?

On Tue, Jan 8, 2013 at 8:09 PM, Richard Schwerdtfeger <schwer@us.ibm.com>
 wrote:

> I am not convinced we can not introduce some caret support in ARIA 1.1.
> ARIA 2.0 is a LONG way off.
>

I think that would be good. I think we could address quite a few use cases
with just some minor changes to ARIA 1.0.

Thanks!

- Dominic