Re: [Events] UI Triggers for IndieUI Events 1.0

On May 22, 2014, at 5:38 AM, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:

> Nice work on the triggers!
> 
> Here are some comments:

Sorry for the late response. I went camping last weekend and am just catching up on this thread.

> Section 3.3 example. 
> 
> I know this is an example but it is in a normative section.
> 
> <change>
> The single event handler is called when a number of physical events occur:
> </change>
> <to>
> The single event handler may be called when a number of physical events occur:
> </to>

May sounds like RFC-2119 MAY which I'd like to avoid. This is an informative example, and I think the language is clearer as-is.

> A similar comment on the example in section 3.4. 
> 
> Section 3.3 suggestion:
> 
> Where you have <section uiactions="dismiss"> consider adding role="dialog"

I used a dialog in another example. The example was intended to show a non-dialog use of "dismiss." It uses a "back" button to indicate slide-in sheets or views, unlike dialogs. This is more like a slide-in view in an iOS or Android settings app than like a "dialog." Maybe an example rendering would help clarify that. 

> Section 4.1 
> 
> editorial: The Element text in the prose be a link or special styling.

Thanks. https://dvcs.w3.org/hg/IndieUI/rev/925c100cd811

> Section 5.1.1 
> "May also need a way to associate IndieUI events with their physical event counterparts."
> 
> Regarding the above comment, if we do this it should be non-normative and it will need to be platform dependent. We could have an authoring practices guide for this - similar to what we did for keyboard for aria. I don't think we want to normatively state the exact key bindings, etc. for a platform as the platform owner may wish to change conventions. 

Responded in the reply to Jason.

> Overall: consider creating a table of uiaction, uitrigger, and uimanipulator token value definitions. It is good to have these all in one place. 

Are you suggesting a table that lists all the tokens and then indicates what they can be used for? e.g. Rows for each action token, and columns for uiaction, uitrigger, uimanipulator?

> I know we spoke about this a somewhat at previous meetings but, regarding manipulation, we are going to have to specify information the author must supply to support it. We could use aria states and properties for some of this. For example if a slider moves request occurs and shows a particular amount we should state what values must be set in the DOM (or and API if the group prefers) to what say the new current value. We should also do things like supply a max and minimum and and increment. I don't think we can do this all in Indie UI. This comment is more for future discussions.

Yes, I agree. I was trying to avoid making IndieUI Events reliant on ARIA, but I think the uimanipulator case is one place where we can't avoid it.

> None of this should hold up putting out the next draft but if you have time to incorporate some of it that would be great. 

I put the change above in the default branch. I didn't put it in the heartbeat branch b/c Michael is trying to publish that tomorrow.

Thanks Rich,
James

> Rich
> 
> James Craig ---05/15/2014 04:08:52 AM---Substantial edits made today/tonight covering the @uittrigger idea we've been discussing over the pa
> 
> From:	James Craig <jcraig@apple.com>
> To:	Indie UI <public-indie-ui@w3.org>
> Date:	05/15/2014 04:08 AM
> Subject:	[Events] UI Triggers for IndieUI Events 1.0
> 
> 
> 
> Substantial edits made today/tonight covering the @uittrigger idea we've been discussing over the past few months. 
> 
> In addition to the rest of the edits, I'd appreciate a critical, technical review of this new section, entitled "UI Triggers."
> https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-events.html#triggers
> 
> Here's the primary commit if you prefer reading diffs.
> https://dvcs.w3.org/hg/IndieUI/rev/cd45845ef058
> 
> This covers one half of ACTION-79 on the IndieUI Events 1.0 product.
> ACTION-79: Explore @uitrigger or @uicontroller (e.g. allows continuous event control for slider thumbs; clickables for dismissrequest, etc.)
> https://www.w3.org/WAI/IndieUI/track/actions/79
> 
> Note: I'm still working on the second piece of ACTION-79 that covers non-discrete, continuous event triggers like slider thumbs.
> 
> Thanks,
> James Craig
> 
> 
> The following is a rich-text paste of the new section, included for convenience. Unfortunately, it does not include all of the generated content, so if you have trouble reading this, please view the editor's draft. Note that rich text is not saved to the mailing list archive, so please read the editor's draft instead of reviewing this from the lists.w3.org archive.
> 
> https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-events.html#triggers
> 3. UI Triggers
> A user interface trigger is an element whose default behavior is to initiate a discrete UIRequestEvent.
> 
> In order to trigger a request event, authors must also register for the event action using the UI Actions Interface on the current element or and ancestor in the DOM. User agents must not initiate a request Event from a trigger element unless the corresponding action is defined on the current element or an ancester element using the uiactionscontent attribute or uiactions IDL attribute.
> 
> Web authors must ensure trigger elements have an appropriate accessible label, as rendered text or a text alternative. Web authors must ensure trigger elements use an appropriate implicit or explicit role (usually button).
> 
> Web authors should ensure trigger elements are focusable. Web authors may avoid making a trigger element focusable if the trigger provides redundant functionality already available through another physical interface. For example, a "delete" trigger may not need to be focusable if pressing the delete key triggers the same request event.
> 
> 3.1 The uitrigger IDL Attribute
> 
> The uitrigger attribute of each instance of the Element interface must return a DOMString reflecting the uitrigger content attribute.
> 
> 
> partial interface Element {
>                attribute DOMString uitrigger;
> };
> 3.1.1 Attributes
> uitrigger of type DOMString,
> A DOM element attribute whose DOMString value reflects the value of the uitrigger content attribute.
> Consider making this attribute a single DOMToken rather than DOMString; this should be single action token value with whitespace trimmed.
> 
> 3.2 The uitrigger Content Attribute
> Every element may have a uitrigger attribute. The attribute, if specified, must have a value that is a single token representing the UIRequestEvent which should be triggered when this element is clicked or otherwise activated.
> 
> User agents must reflect the uitrigger content attribute in the uitrigger IDL attribute.
> 
> All uitrigger token values
> 
> 	• collapse
> 	• delete
> 	• dismiss
> 	• expand
> 	• medianext
> 	• mediapause
> 	• mediaprevious
> 	• mediastart
> 	• mediastop
> 	• mediatoggle
> 	• redo
> 	• undo
> 
> NOTE
> The uitrigger tokens list is a subset of the entire uiactions tokens list. It only lists actions associated with discrete UIRequestEvent types. It does not list actions associated with interfaces that extend UIRequestEvent, such as UIManipulationRequestEvent or UIScrollRequestEvent, because those require additional parameters that cannot be determined by a simple click or activate event on the trigger element.
> 
> 3.3 Example "Back" Button with Dismiss Request Trigger
> 
> The following example demonstrates a view that can be "dismissed" with a "back" button trigger, the esc key, or other appropriate physical events using a single event handler.
> 
> EXAMPLE 4
> 
> <section uiactions="dismiss">
>  <!-- "Back" button acts as the dismiss trigger if clicked or activated. -->
>  <button uitrigger="dismiss"> Back </button>
>  ... other view contents ...
> </section>
> 
> <script type="text/javascript">
>  // A single event handler for a number of user events.
>  function handleDismiss(e) {
>    // Dismiss the current view.
>    dismissView(e.receiver); // Event.receiver is a readonly property like Event.target 
>    // Then cancel the event.
>    e.stopPropagation(); // Stop the event from bubbling.
>    e.preventDefault(); // Let the UA/AT know the event was intercepted successfully.
>  }
>  document.body.addEventListener("dismissrequest", handleDismiss);
> </script>
> 
> The single event handler is called when a number of physical events occur:
> 	• When the user presses the esc key while focus is inside the view.
> 	• When the "back" button is clicked via a mouse or other pointing interface.
> 	• When the "back" button is focused and activated via a keyboard or other keyboard-like interface.
> 	• When other physical events are initiated that convey the user's desire to dismiss or escape from the current view, such as the VoiceOver screen reader's "two-finger scrub" gesture.
> 3.4 Media Player Example with Media Key Triggers
> The following example demonstrates a custom media player that uses the same event handler whether a button was activated, a keyboard media key was pressed, or a headphone remote was clicked.
> 
> EXAMPLE 5
> 
> <body uiactions="mediaprevious mediatoggle medianext">
>  <button uitrigger="mediaprevious"> Previous Track </button>
>  <button uitrigger="mediatoggle"> Play/Pause </button>
>  <button uitrigger="medianext"> Next Track </button>
> </body>
> 
> <script type="text/javascript">
>  // A single event handler for a number of user events.
>  function handleMedia(e) {
>    
>    // Handle the media events from any physical event source.
>    switch (e.type) {
>      case "mediapreviousrequest":
>        previousTrack();
>        break;
>      case "mediatogglerequest":
>        togglePlayback();
>        break;
>      case "medianextrequest":
>        nextTrack();
>        break;
>      default:
>        return; // Event not handled, so return early to prevent canceling event.
>    }
> 
>    // Then cancel the event.
>    e.stopPropagation(); // Stop the event from bubbling.
>    e.preventDefault(); // Let the UA/AT know the event was intercepted successfully.
>  }
> 
>  document.body.addEventListener("mediapreviousrequest", handleMedia);
>  document.body.addEventListener("mediatogglerequest", handleMedia);
>  document.body.addEventListener("medianextrequest", handleMedia);
> </script>
> 
> The single event handler is called when a number of physical events occur:
> 	• When the user presses the media keys on their physical keyboard.
> 	• When the user clicks the cable remote on on their headphones.
> 	• When any of the buttons is clicked via a mouse or other pointing interface.
> 	• When any of the buttons is focused and activated via a keyboard or other keyboard-like interface.
> 	• When other physical events are initiated that convey the user's desire toggle media playback, such as the VoiceOver screen reader's "two-finger double-tap" gesture.
>