On Fri, Nov 5, 2010 at 6:40 PM, James Robinson <
jamesr@google.com> wrote:
> On Fri, Nov 5, 2010 at 6:32 PM, James Craig <
jcraig@apple.com> 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.
>>
>> DOMAttrModified
>> 1. An attribute in the DOM changes (for whatever reason).
>> 2. UA fires DOMAttrModified. This may recursively fire a series of other
>> mutation events, hence the performance problems.
>> 3. Web application (web page author) can do whatever, but this is a
>> notification of the change, not a request to make the change.
>>
>> DOMAttributeChangeRequestEvent
>> Path 1: ignored by the web application, so no DOM change occurs.
>> 1. User performs some UI action. (e.g. VoiceOver user may press
>> Ctrl+Opt+\)
>> 2. AT interprets the intent of that action. (In VoiceOver, that key combo
>> means expand or collapse a tree node.)
>> 3. UA fires a single DOMAttributeChangeRequestEvent (e.g. "Web
>> application, please change 'aria-expanded' value of Node to 'true'")
>> 4. Web application (web page author) ignores the event, so no DOM change
>> occurs.
>> 5. AT receives the unsupressed/uncancelled event at the end of the bubble
>> phase. (e.g. VoiceOver may beep to indicate to the user that no change
>> occurred.)
>>
>> DOMAttributeChangeRequestEvent
>> Path 2: received by the web application, which makes the change on the
>> user's behalf.
>>
>> 1. User performs some UI action. (e.g. VoiceOver user may press
>> Ctrl+Opt+\)
>> 2. AT interprets the intent of that action. (In VoiceOver, that key combo
>> means expand or collapse a tree node.)
>> 3. UA fires a single DOMAttributeChangeRequestEvent (e.g. "Web
>> application, please change 'aria-expanded' value of Node to 'true'")
>> 4. Web application (web page author) has registered for the event, and
>> receives it.
>> 5. Web application (web page author) interprets the "request", and
>> calls Node.setAttribute('aria-expanded', 'true')
>> 6. Web application (web page author) cancels or suppresses the
>> event. (e.g. "UA, I have received your request, and have changed this DOM
>> attribute on your behalf.")
>> 7. AT receives the supressed/cancelled event which indicates that the
>> 'request' was successful.
>> 8. AT can indicate to the user what happened. (e.g. VoiceOver might review
>> the AX API and speak "expanded. 7 items enclosed.")
>>
>>
>> Or, phrased another way:
>> 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."
>
> This is far worse than an async DOMAttrModified since it means that all code
> that attempts to change an attribute has to deal with the case where the
> page cancels the change or makes arbitrary other changes. It also has worse
> performance characteristics since it means that the browser would have to
> fire the DOMAttributeChangeRequestEvent synchronously when it wanted to
> change the attribute and wouldn't be allowed to batch up the events at all.