On Nov 2, 2010, at 12:48 PM, Ojan Vafai wrote: > On Oct 27, 2010, at 2:57 PM, James Craig wrote: >> James Craig responded: >>>> The main difference seems to be that our Undo and Redo *request* allows >>>> the web application to determine what (if anything) should be undone, or >>>> redone, where the HTML5 undo manager requires that the user agent make the >>>> change directly to the DOM or editable content. The UIRequestEvent >>>> interface allows the app to determine the outcome of the events based on >>>> the business logic of the app, which the browser does not know about. > I don't really understand how putting "request" in the name of the event is > useful. There are plenty of existing events that "allows the app to determine > the outcome of the events based on the business logic of the app" but aren't > request events.
The best explanation I have for it now is the following paragraph, or the intro section in the proposal. >>>> The reason these are all called 'request' events is because they don't >>>> change anything. They only send a 'request' to the web application (not to >>>> the user agent) to make a change on the user's behalf. The web application >>>> can then intercept or ignore the event as needed. If ignored (if the web >>>> app hasn't registered that event listener, or if the event is not canceled >>>> with preventDefault) then the user agent or assistive technology can fall >>>> back to whatever behavior is deemed appropriate, including then using the >>>> HTML5 undo manager. >> Back to Tony's email: >>> Ojan also proposed renaming the textInput event to just beforeInput because >>> it seems like it can apply to more than just text (e.g., undo'ing the >>> insertion of an image). Do you think the use of textInput/beforeInput >>> would meet the use cases needed by UIRequestEvent? >> In some cases, it may be appropriate, but my response to the previous >> question may provide additional understanding of why textInput/beforeInput >> is not sufficient, and why these two proposals are not mutually exclusive, >> even if they do overlap in some places. > > I still don't see why beforeInput would not be sufficient. It might be more > clear if you enumerated the list of things you expect to have UIRequestEvents > for. There are several examples in the proposal, including: Users, wanting to change the value of a custom range widget (ARIA slider, ARIA media progressbar, etc.) in a web application, can indicate their intent a number of ways, including pressing various keys (up, down, left, right, pageup, pagedown, home, end) on most keyboard-controlled interfaces, and through gestures on many touch-enabled interfaces. User agents understanding this intent should initiate a ValueChangeRequest event. Web authors who have registered for this event, should process the event to determine whether to cancel the event. If the value change action is understood in the context of the web application, web authors should change the value of the associated widget by an amount determined via the changeType argument, and cancel the event using the event object's ---() method. If the event is not cancelled by the web author, user agents may pass the literal interaction event to the web application; in this case, in the form of a keypress event. We plan to include more examples in a later draft. >> As I stated in the bug tracker comments, the W3C DOM and PF working groups >> discussed this, and the outcome was to work on a standalone specification as >> a joint effort of the two groups. The initial document editors will likely >> be Doug Schepers (W3C staff contact for www-dom) and me. From the >> teleconference discussions, these will be an add-on to DOM 3 Events and/or >> ARIA 1.0, because both of those documents are currently in Last Call. The >> only major change to the proposal so far that we're discussing a new method >> to the Event object (perhaps 'suppressEvents' or 'suppressRelatedEvents') so >> that we don't have to cancel the event by overloading the original use of >> the preventDefault method. > What's the difference between preventDefault and suppressEvents? preventDefault only prevents the default action of the current event. supressEvents would allow the author to inform the user agent that any remaining events for the same user interaction are no longer relevant. For example, if the user pressed either Delete key and the application intercepted the DeleteRequest event, it could call Event.suppressEvents() (or whatever we call it) to indicate that the related events (keydown, keyup, keypress) are no longer needed, and the user agent should not fire them. > Also, earlier in this thread, you said that you don't know of anything that > requires these events to be synchronous, but that seems to contradict James's > point above and the patch in question fires the events synchronously. The > spec text all also implies that the event fires, then application has the > chance to prevent it and then the action happens. So, unless I'm misreading, > the events need to be synchronous and fire before the associated action > occurs. All events are like that. For example, a 'click' event on a link can prevent the web view from navigating to the link's href URL. The event sequence needs to happen in order and the action within the web view should wait for the event to complete, but I don't believe this needs to be synchronous between the browser and a web view running in a separate thread. > To be clear, my concern so far has just been about UIRequestEvent, which > seems to overlap 100% with beforeInput. Everything I've read about input events implies they are limited to form inputs. UIRequestEvent, for example, could be used to undo the last action, such as "undo close file", or "undo move message to trash", where the input events could not. > Some other concerns with the proposal: > -UIScrollRequestEvent: Don't we already have a scroll event? Can we just add > a scrollType property to it? Scroll event happens after the fact, and doesn't work on custom scroll areas, and neither scroll event or wheel event are allowed to suppress related events. > -UIValueChangeRequestEvent: This doesn't seem generic enough for the example > listed. For example, with a range widget, lets say the range is from 1-10 and > the user tries to move it from 2 to 5. That would be a valid use case if there were a way to specify valid values within a particular range. That's currently deferred to ARIA 2.0: Issue 51, How should we address the issue of datatypes and formatters in ARIA? From the comments, "There may also need to some hint of increment value if it cannot be determined from the value format or other range data." If you have a W3C member account, you can view it here: http://www.w3.org/WAI/PF/Group/track/issues/51 > Is that an INCREMENT_SMALL or INCRMENT_LARGE? If it's just INCREMENT, > shouldn't there be some way to communicate the amount it changed? That's for the application to determine. INCREMENT is roughly equivalent to Right arrow or Up arrow (depending on locale) INCREMENT_LARGE is roughly equivalent to PageUp INCREMENT_SMALL is roughly equivalent to Opt/Alt+Right or Opt/Alt+Up (depending on the OS or application) > -DOMAttributeChangeRequestEvent: The spec text is pretty vague as to what > should and shouldn't fire this. With the spec text, without the note/example, > this event sounds a lot like DOMAttrModified and has all the associated > problems. There's a note that claims it doesn't have the same problems, but I > don't see how that's the case. I'd be happier with this if it were explicitly > about ARIA attributes, i.e. AriaChangeEvent. I agree that this should be speced, but I don't think it should be limited to ARIA.
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
