On Nov 5, 2010, at 7:03 PM, James Robinson wrote:

> On Fri, Nov 5, 2010 at 6:52 PM, Adam Barth <[email protected]> wrote:
>> I could be misunderstanding, but it sounds like these events originate with 
>> the AT software rather then when the DOM is modified.  In that sense, they 
>> sound more like KeyDown than DOMAttrModified.
> 
> I see - in that case the name doesn't seem very good, if the expectation is 
> that this event will only be generated from AT software and not by any other 
> mechanisms that result in attributes changing values.  Do we need this for 
> any attribute that could change values, or just AX-related ones?

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

> What happens if a single user action results in a large number of attributes 
> changing values?

Do you have something in mind that may cause this? Part of what needs to be 
specified is what the user agent should request (and how often) when it 
interprets the intent of a particular user action, and I don't foresee the need 
for piling on a series of DOMAttributeChangeRequests. 

There are some cases where UIScrollRequests or UIValueChangeRequests might pile 
up. The spec should probably handle the case of key repeat; for example, what 
happens if an author has registered for UIScrollRequest and the user falls 
asleep on the PageDown key. We may want a way for the app to say "suppress this 
series of repeated request events."

James

_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Reply via email to