<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>Ojan Vafai&nbsp;wrote:</div></div><br><blockquote type="cite">How is [&nbsp;DOMAttributeChangeRequestEvent ]&nbsp;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.</blockquote><blockquote type="cite"><blockquote type="cite"></blockquote></blockquote><div><br></div><div><br></div><div>DOMAttrModified&nbsp;is a notification, but&nbsp;DOMAttributeChangeRequestEvent&nbsp;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.</div><div><br></div><br><div><div><b>DOMAttrModified</b></div></div><div><br></div><div>1. An attribute in the DOM changes (for whatever reason).</div><div>2. UA fires DOMAttrModified. This may recursively fire a series of other mutation events, hence the performance problems.</div><div><b>3.&nbsp;Web application (web page author) can do whatever, but this is a notification of the change, not a request to make the change.</b></div><div><br></div><div><br></div><div><div><b>DOMAttributeChangeRequestEvent</b></div><div>Path 1: ignored by the web&nbsp;application, so no DOM change occurs.</div></div><div><br></div><div>1. User performs some UI action. (e.g. VoiceOver user may press Ctrl+Opt+\)</div><div>2. AT interprets the intent of that action. (In VoiceOver, that key combo means expand or collapse a tree node.)</div><div>3. UA fires a single&nbsp;DOMAttributeChangeRequestEvent (e.g. "Web application, please change 'aria-expanded' value of Node to 'true'")</div><div><b>4. Web application (web page author) ignores the event, so <i>no DOM change occurs</i>.</b></div><div>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.)</div><div><br></div><div><br></div><div><b>DOMAttributeChangeRequestEvent</b><br>Path 2: received by the web application, which makes the change on the user's behalf.<br><br>1. User performs some UI action. (e.g. VoiceOver user may press Ctrl+Opt+\)<br>2. AT interprets the intent of that action. (In VoiceOver, that key combo means expand or collapse a tree node.)<br>3. UA fires a single DOMAttributeChangeRequestEvent (e.g. "Web application, please change 'aria-expanded' value of Node to 'true'")<br>4. Web application (web page author) has registered for the event, and receives it.</div><div><b>5.&nbsp;Web application (web page author) interprets the "request", and <i>calls&nbsp;Node.setAttribute('aria-expanded', 'true')</i></b></div><div>6.&nbsp;Web application (web page author) cancels or suppresses the event.&nbsp;(e.g. "UA, I have received your request, and have changed this DOM attribute on your behalf.")</div><div>7.&nbsp;AT receives the supressed/cancelled event which indicates that the 'request' was successful.</div><div>8. AT can indicate to the user what happened. (e.g. VoiceOver might review the AX API and speak "expanded. 7 items enclosed.")</div><div><br></div><div><br></div><div><br></div><div>Or, phrased another way:</div><div><br></div><div><b>DOMAttrModified</b></div><div>"I took your dollar. By the way, my dad and granddad are probably gonna some cash from you, too."</div><div><br></div><div><b>DOMAttributeChangeRequestEvent</b></div><div>Path 1: "Can I have a dollar? No? Okay."</div><div>Path 2: "Can I have a dollar? Yes? Sweet."</div><div><br></div><div><br></div></body></html>