This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 6653 - [ARIA 2.0] How should web devs monitor attribute changes?
Summary: [ARIA 2.0] How should web devs monitor attribute changes?
Status: RESOLVED FIXED
Alias: None
Product: ARIA
Classification: Unclassified
Component: Core AAM (show other bugs)
Version: 1.0
Hardware: PC All
: P3 normal
Target Milestone: Last Call
Assignee: David Bolter
QA Contact: ARIA UA Implementors
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-05 15:46 UTC by David Bolter
Modified: 2013-03-22 18:04 UTC (History)
4 users (show)

See Also:

Attachments

Description David Bolter 2009-03-05 15:46:53 UTC 
During some discussion over IRC yesterday Olli Pettay suggested that a performant way of implementing DOM attribute mutations might be to have separate but similar API to DOMAttrModified.

Note DOMAttrModified would serve the same purpose, but having the browser create DOM mutation events for all mutations is going to slow the web experience.

ARIAAttrModified is tabled as a way of only creating mutation events for aria attributes.

Background: why do we need these mutations? In the case that an aria-attribute is modified, not by the web developer (perhaps through platform API), for example aria-sort is set to "true", the web developer is supposed to respond to that change (a dom attr mutation), and put his web application into a state that corresponds with the aria-sort="true" semantic.
Comment 1 David Bolter 2009-04-14 19:28:02 UTC 
For those with access, please note: http://www.w3.org/WAI/PF/Group/track/issues/201
Comment 2 David Bolter 2009-04-22 01:20:05 UTC 
I'm not sure if this is a priority, since I'm not convinced of the use cases yet. It really boils down to whether we think AT will make use of setting ARIA attributes to drive DHTML behaviour.

I personally would like WAI-ARIA to provide state information passively, and I don't expect web authors to list for ARIA attr dom mutation, or to handle them appropriately.
Comment 3 Andi Snow-Weaver 2009-06-12 15:09:39 UTC 
Might discuss with aria-activedescendent or in section 4 on Managed states. Best Practices Guide discusses so we probably should address in UAIG.
Comment 4 Andi Snow-Weaver 2010-01-05 15:16:04 UTC 
Not something the AAPI group can solve. Needs to be taken up by the DOM events group. David to contact them.
Comment 5 David Bolter 2010-01-05 18:21:38 UTC 
Hmm, okay so I spoke to a DOM guy and he suggested we should define our own event if we need it.
Comment 6 Andi Snow-Weaver 2010-01-12 16:39:13 UTC 
So what's the next step David? Is this something the API owners have to do?
Comment 7 David Bolter 2010-01-12 17:31:25 UTC 
This bug isn't high priority for browsers that already implement DOMAttrModified.
(http://www.quirksmode.org/dom/events/)

Also: it is only really necessary to make aria-activedescendant more usable by web developers; where an alternative for them is to poll in js.
Comment 8 David Bolter 2010-01-13 20:46:33 UTC 
Interesting: http://www.w3.org/2008/webapps/wiki/Selector-based_Mutation_Events
Comment 9 Andi Snow-Weaver 2010-02-09 16:51:31 UTC 
See e-mail thread on DOMAttrModified being deprecated starting at: http://lists.w3.org/Archives/Member/w3c-wai-pf/2010JanMar/0084.html
Comment 10 Andi Snow-Weaver 2010-02-09 16:52:14 UTC 
See e-mail thread on DOMAttrModified being deprecated starting at: http://lists.w3.org/Archives/Member/w3c-wai-pf/2010JanMar/0084.html
Comment 11 David Bolter 2011-07-22 19:47:32 UTC 
Olli, any news on this topic? I've not followed it.