Hi Ojan, You reviewed- the first pass at an implementation of this proposal
https://bugs.webkit.org/show_bug.cgi?id=47301 but haven't responded to this thread. Do you have any other objections. On Oct 27, 2010, at 2:57 PM, James Craig wrote: > Sorry for the delayed response, Tony. My answers inline. > > On Sep 3, 2010, at 9:35 AM, Tony Chang wrote: > >> I'm curious what elements the UIRequestEvents apply to. Does it fire at the >> document level or does it fire for specific elements like textareas? > > Focused element (or AX-focused element) where appropriate. Document body > otherwise. > > For example, the scroll request events should be fired on the focused node so > they can bubble up the DOM tree, so any node that needs to intercept it can. > An example of when this may be inappropriate to fire on a lower-level node > DOM is in the case of a browsing context that does not have a focus model > where something always has focus; e.g. many touch-screen mobile devices do > not have a focused element unless a form element is selected, or an assistive > technology application is running on top of the rendering engine. In this > case, firing at the document level would be appropriate. > >> The addition of undo/redo is similar to the proposal to add this to the >> textInput event. There was some discussion of that here: >> http://lists.w3.org/Archives/Public/www-dom/2010AprJun/0082.html > > This may be answered my response to Doug Schepers' related question in this > email from the www-dom list. > http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0051.html > > Quoting from that thread: > > Doug Schepers wrote: >>>> Note also that HTML5 defines editing actions and APIs [6], specifically >>>> the UndoManager interface [7]. > >>>> [7] http://www.w3.org/TR/html5/dnd.html#undomanager > > 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. > >>> >>> 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. > > 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. > > Thanks for your questions. We realize the proposal may not be clear unless > the reader knows a lot about 1) screen readers and 2) WAI-ARIA, but we hope > to improve the understandability of the document in future iterations. > > Cheers, > James Craig >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
