On Mon, Nov 1, 2010 at 1:03 PM, Chris Fleizach <cfleiz...@apple.com> wrote:
> You reviewed- the first pass at an implementation of this proposal > Sorry for not responding sooner. > https://bugs.webkit.org/show_bug.cgi?id=47301 > > but haven't responded to this thread. Do you have any other objections. > Yes, but I don't know much about screen readers or ARIA, so I might just not understand the proposal. > 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 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. > 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? 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. To be clear, my concern so far has just been about UIRequestEvent, which seems to overlap 100% with beforeInput. Some other concerns with the proposal: -UIScrollRequestEvent: Don't we already have a scroll event? Can we just add a scrollType property to it? -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. 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? -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. Sorry again for not responding sooner. Ojan >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev