On Nov 10, 2010, at 3:40 PM, Ojan Vafai wrote: > Heh. There's clearly still a good deal of confusion about what the intended > behavior here is. Well, I'm confused anyways. :) > > On Fri, Nov 5, 2010 at 9:32 PM, James Craig <[email protected]> wrote: >> Ojan Vafai wrote: >>> How is [ DOMAttributeChangeRequestEvent ] any different than >>> DOMAttrModified? The spec claims it doesn't have the problems that >>> DOMAttrModified has, but I don't see how that's the case. >> DOMAttrModified is a notification, but DOMAttributeChangeRequestEvent is a >> request. The reason these all inherit from UIRequestEvent is because they >> are all requests, not notifications. For example, the following sequences >> may occur in a real user scenario. > > I think this is the core of my confusion. In some cases I get that these > events are requests. In this case, it's a request to change an attribute. But > there are other cases where it seems like they have a default action. For > example, when the user scrolls, we fire a UISrollRequest and if the web page > does nothing, then the page scrolls, right? And if they user hits the delete > key, we fire a DeleteRequest and delete if the web page doesn't cancel it. > But then the AT software can also fire a DeleteRequest that does nothing if > the web page doesn't cancel it? > > Am I misunderstanding? If the events are always requests with no default > action, calling these request events might make sense, but then it seems that > these would only be for AT software and should be named appropriately.
>From another email to the list (On Nov 5, 2010, at 7:29 PM, James Craig wrote): The primary need is for assistive technology, but there are several cases where this is appropriate in a mainstream user agent. For example, some mobile devices have a "scroll to top" feature if you click on the status bar chrome just outside the web content view. For web apps with custom scroll views (e.g. those that accept touchstart and touchend), it may be appropriate for the user agent to fire a single UIScrollRequest with a scrollType value of TOP_LIMIT. http://lists.w3.org/Archives/Public/wai-xtech/2010Aug/att-0079/UserInterfaceIndependence.html#UIScrollRequestEvent > My first intuition is that we should not try to do AT specific events *if* we > can avoid it because web developers will largely ignore them, but I'd like to > understand the current proposal first. I agree, but even if these were AT-specific events, I don't think we could avoid them. There is currently no good way for assistive technology to control a web application. The existing de facto approaches are a crappy workaround at best. That's what the problem description is about: http://lists.w3.org/Archives/Public/wai-xtech/2010Aug/att-0079/UserInterfaceIndependence.html#problem >> DOMAttrModified >> "I took your dollar. By the way, my dad and granddad are probably gonna some >> cash from you, too." >> >> DOMAttributeChangeRequestEvent >> Path 1: "Can I have a dollar? No? Okay." >> Path 2: "Can I have a dollar? Yes? Sweet." > > Heh. I see they these are different. DOMAttributeChangeRequestEvent is not > actually a notification that something changed or that something is about to > change? Correct. It's up to the web application to make any requested changes. In this case, to hand out the cash… or not. James _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
