DOM3 Events Review

Feedback to the DOM WG

Please put specific wording of feedback to the DOM WG here. PFWG will review and assemble the formal response. Resources later in this page may be useful in preparing this.

DOM3 Events Resources

• DOM Level 3 Events Last Call Working Draft (2010-09-07)
  • Section 5.2.6: Keyboard Event Types
  • DOMActivate (event type)
  • Focus event types
  • Section 5.2.8 Mutation Events
    • DOMAttrModified
  • Mutation Replacement (WebApps Wiki Page)
    • Web Apps Wiki

Critical Sections of DOM3 Events

DOMAttrModified

• Type: DOMAttrModified
• Interface: MutationEvent
• Syncronous / Asyncronous: Synchronous
• Bubbles: Yes
• Target: Element
• Cancelable: No
• Default action: none
• Context info:
  • Event.target: element whose attribute is being modified
  • MutationEvent.attrName: the name of the changed Attr node
  • MutationEvent.attrChange: the numerical code corresponding to the most applicable attrChangeType
  • MutationEvent.relatedNode: the Attr node that has been modified, added, or removed.
  • MutationEvent.newValue: new value of the attribute, if the Attr node has been added or modified
  • MutationEvent.prevValue: previous value of the attribute, if the Attr node has been removed or modified

A user agent must dispatch this event after an Attr.value has been modified and after an Attr node has been added to or removed from an Element. The proximal event target of this event shall be the Element node where the change occurred. It is implementation dependent whether this event type occurs when the children of the Attr node are changed in ways that do not affect the value of Attr.value.

Warning! the DOMAttrModified event type is defined in this specification for reference and completeness, but this specification deprecates the use of this event type.

Current Discussion of DOM3 Events in PFWG

Complilmentary Discussions/Documents

• User Interface Independence by James Craig & Chris Fleizach
  • UI Device Independence Proposal Discussion (Hypertext Coordination Group Meeting) 2010-10-08

Current Discussions of DOM3 Events on w3c-wai-pf

• (DOM3 Events) DOMAttrModified deprecation (PFWG ACTION-712)
  • PFWG Action-712
• Re: (DOM3 Events) DOMAttrModified deprecation (PFWG ACTION-712)
  • User Interface Independence (DOMAttributeChangeRequestEvent) proposal

• DOM 3 Activation triggers and behavior section (Michael Cooper)
  • Re: DOM 3 Activation triggers and behavior section (James Craig)

Previous Discussion of DOM3 Events in PFWG

Previous Discussions of DOM3 Events on w3c-wai-pf

• DOM Activate Resolution--48 Hour Call for Objections (Janina Sajka)
  • Re: DOM Activate Resolution--48 Hour Call for Objections (GJR)

• HEADS UP! DOM3Events: Major Change finalization due Wednesday (Janina Sajka)
  • "1) DOMActivate: having looked into this in some depth, we are currently of the opinion that it may be better for all involved (accessibility folks included) to deprecate DOMActivate and expand the semantics and behavior of the "click" event type to include the full range of situations and devices that DOMActivate now covers; this would clarify and justify the process already started by browser implementers. Focusing on a single event type would make an easier and more consistent model for implementers and content authors, which would lead to better interoperability; the unfortunate naming convention can be seen as a historical accident."
  • "2) Mutation Events: these are reviled by browser vendors and many authors because of difficulty of implementation and poor performance; this is unfortunate for ARIA and other accessibility tech because that is the circumstance where good performance is most needed. We plan to deprecate Mutation Events and provide an alternate notification API that would have better performance. We would like to work with the PFWG to ensure that this meets all the needs of ARIA, etc., and perhaps to bake in direct hooks for AT notification APIs, to make it an intrinsic part of the architecture rather than something bolted on."

• DOMActivate vs. Activation Behavior (Doug Schepers)
  • Re: DOMActivate vs. Activation Behavior (GJR)

• Deprecation of DOMAttrModified (Was: DOMActivate vs. Activation Behavior) (James Craig)
  • "DOMAttrModified is deprecated, but as far as I can tell, there is no suitable replacement. We'll need this (or something equivalent) in order to allow platform-, modality-, and device-independant access on anything other than the default action, which could be determined via click or DOMActivate. For example, on a treeitem element DOMActivate could indicate the default action of selection, but without DOMAttributeModified, there is no way for the user's assistive technology to convey the intent of a non-default action, such as expanding or collapsing the tree node. This currently relies on the author to assign de facto standard key events such as the left and right arrow keys. The deprecation of DOMAttrModified blocks the ARIA 2.0 issue of device-independence."
  • "For example, the iPhone screen reader interface is completely gestural, without a keyboard unless the user is editing a text field. Although there could be a gesture to let the user convey their intent ("expand this tree branch") to the screen reader and user agent, there is no way for the user agent to convey that intent to the web application. DOMAttrModified or an equivalent event allows the web application to be notified when the specific DOM change occurs (e.g. @aria-expanded changed from "false" to "true") so the web application can update any relevant view after the attribute value has changed."
  • "For what it's worth, I don't foresee much need for rest of the mutation events (I could live with their deprecation), but DOMAttrModified is very useful from an accessibility perspective"
  • Re: Deprecation of DOMAttrModified (Jonas Sicking)
  • Re: Deprecation of DOMAttrModified (David Bolter)
    • "The idea is that AT can (through API) cause the modification of an attribute, and the web developer should have a standard way to tell that modification happened (without js timer/polling). For example perhaps visual focus changes (aria-activedescedant). That said, I'm not sure if this pattern is used a lot today"
  • Re: Deprecation of DOMAttrModified (James Craig)
  • Re: Deprecation of DOMAttrModified (James Craig)
    • "What we need (does not exist other than through the deprecated, DOMAttrModified): If an assistive technology user wants to do something other than the default "activation behavior" (for example, sort a table by the current cell's column), they convey that to the assistive technology (in VoiceOver, they'd use VO+vertical bar), which could then convey that to the user agent through the accessibility API, and the user agent could set the DOM attribute 'aria-sort' to 'ascending' or 'descending'... This much could work today, except that a web application author has no notification alerting them that the table grid's sort order has changed, so the controller is unlikely to know that it needs to update to view to reflect the new sort order."
  • Re: Deprecation of DOMAttrModified (James Craig)
  • Re: Deprecation of DOMAttrModified (Jonas Sicking)
    • "I think it's generally agreed that we need a replacement for mutation events such as DOMAttrModified. There's so far been two proposals, one from Travis Leithead of microsoft, and one from me. I don't know where we'll end up, but I think it's safe to say that it's unlikely that any browser that currently supports mutation events will remove that support before a replacement is available."
    • "It does however strike me as scary that AT is modifying web pages and expecting web pages to react to these modifications. I would imagine most authors will not be aware that they need to do this, and that it's unlikely that they'll do that incorrectly even if they are aware. However I know nothing about why this behavior exists so I'd say it's almost certain things work differently than what I'm imagining."
  • Re: Deprecation of DOMAttrModified (Joseph Scheuhammer)
    • "Without DOMAttrModified, the web app is completely unaware that the sort-order for that element has changed."
  • Re: Deprecation of DOMAttrModified (James Craig)
    • "It's for device and platform independence. I mentioned the touch screen example; another reason is that, with the ARIA 1.0 release, keyboard control of web apps is left up to the author to manage with a de facto set of keyboard commands. It'd be inappropriate for a W3C spec to define user interface like these keyboard commands, so they're currently in a non-normative document. The shortcuts used are also somewhat Windows-centric, in my opinion."
    • "The more robust future solution would be to have an AT user interact with a web application in the same manner they'd interact with a native OS application, including all the same keyboard shortcuts. That ideal won't be implemented for quite some time, hence its deferral to ARIA 2.0, but DOMAttrModified, or a suitable replacement, is one of the puzzle pieces we'll eventually need"
  • Re: Deprecation of DOMAttrModified (Sean Hogan)
  • Re: Deprecation of DOMAttrModified (James Craig)
  • Re: Deprecation of DOMAttrModified (Jonas Sicking)
  • Re: Deprecation of DOMAttrModified {Doug Schepers}
    • "... Mutation Events are especially poor performance-wise, it's actually a serious accessibility issue that ARIA relies upon DOMAttrModified. Basically, the problem is that there is overhead involved in the DOM Events model, and that changes made to the DOM as a result of a mutation event would trigger additional mutation events, etc., setting up race conditions and eating up memory. This is exacerbated in the AT case, because users of AT may not have other means to detect when the system is locked up or busy (the little spinning hourglass or beachball), so if they don't receive immediate feedback, they may inadvertently trigger the same mutation event multiple times trying to activate a control."
    • "The use case you describe is real, and applies to more than AT, so we definitely need to have a replacement for the functionality, but one which is less likely to lead to a bad user experience. There are a couple solutions we are working on that don't rely upon events, but rather a new notification system (perhaps based on the selectors API) Proposed Solution 1: Attribute Changed Proposed Solution 2: Replacing Traditional Mutation Events. Because it doesn't have the overhead of the event object initialization and event propagation path, and is asynchronous, it can actually perform much more responsively."
  • Re: Deprecation of DOMAttrModified (James Craig)
    • "This seems like a pretty good idea to me. One question though: This appears to be a good solution for attributes that have a limited number of values (e.g. true/false) but what about attributes that may contain IDREFs or string values. For example, if the 'active descendant' in a list of 10,000 items changes, does the proposed model require me to watch each possible value? ... Or, could I just watch for a change in that value?"
  • Re: Deprecation of DOMAttrModified (James Craig)
  • Re: Deprecation of DOMAttrModified (Jonas Sicking)
  • Re: Deprecation of DOMAttrModified (James Craig)
  • Re: Deprecation of DOMAttrModified (Jonas Sicking)
  • Re: Deprecation of DOMAttrModified (James Craig)
    • "My request was to retain DOMAttrModified or provide a suitable replacement. I don't have any particular attachment to the current mutation event model, as long as there is a long term goal to provide a standardized method for author notification when a specific attribute changes."
  • Re: Deprecation of DOMAttrModified (Rich Schwerdtfeger)
    • "this change will break more than just screen readers. It will break magnifiers, alternate input devices, etc., and accessibility test tools across all the platforms. We need to consider a deprecation runway to get these applications to adapt. These applications just don't sit there and poll the browser. Essentially, if we are not careful we will put the whole ecosystem casters up. If this is being planned we should look at the typical development release cycles for the major ATVs. and time it properly."
    • "What I would do is state that an event is being deprecated and give ATVs a runway to switch over before turning off the old event model. Like anything else, the ATs will still be left with the baggage of supporting the old browsers. For example, they are still saddled with IE6 support as many customers have no reason to switch. We should also consider doing the unthinkable and tell the ATVs the browser release time frame for this change."
  • Re: Deprecation of DOMAttrModified {Doug Schepers}
    • "The deprecation strategy we have outlined is exactly intended to transition from these poorly-supported events to equivalents which, by their more efficient design, are apt to be implemented more widely and thus enable better accessibility. Note again that we are not removing the events, but deprecating them in favor of replacements."
  • Re: Deprecation of DOMAttrModified {James Craig}
    • "I'm not sure what Rich is referring to either. These things don't work yet, so my goal is to allow them to work someday (via DOMAttrModified or one of the other proposed mechanisms). Since there are no existing implementations, I can't see how this would 'break' anything"

• Deprecating DOMActivate Event (Doug Schepers)
• DOM3Events: HEADS UP -- Major Change Proposed (Janina Sajka)

Discussion of DOM3 Events at PFWG Teleconferences

• UIDI and DOM3 Event Discussion with members of WebApps WG
• DOM3 Events discussion at PF Weekly Telecon (2010-09-22)
• PF Weekly Telecon 2010-09-07
• PF Weekly Telecon 2010-09-01
• Deprecating DOM Activate (PF Telecon with Doug Schepers, 2010-03-31)
• A request from the Web applications working group on dom activate and alternatives to mutation events (PF Telecon 2010-02-10)
• Finalize DOM3 Guidance: Activate, Mutation Events (PF Telecon 2010-01-27)
• DOM3 Coordination with Travis & Olli (PF Telecon 2010-01-13)