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 15438 - Details node needs to fire event when opened or closed
Summary: Details node needs to fire event when opened or closed
Status: RESOLVED DUPLICATE of bug 14101
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC Linux
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-06 05:54 UTC by Michael A. Peters
Modified: 2012-01-06 20:21 UTC (History)
4 users (show)

See Also:


Attachments

Description Michael A. Peters 2012-01-06 05:54:20 UTC
The html5 details node needs to fire an event when the rendering of the details are toggled between displayed or hidden.

There may be JS action that a page needs to do when a details node changes state. Currently it appears there are 3 options:

1) Have a script constantly running checking for an open attribute every n seconds. Such polling scripts are an un-necessary use of resources for an element that is unlikely to have its state changed very often and is bad practice.

2) Use the DOMAttrModified event - but that event appears to be deprecated and is not available in current versions of some browsers (including chrome)

3) Use the DOMSubtreeModified event - but that event is also deprecated. It works in chrome, but will fire when there changes to the details node or its children that are not related to toggling the rendering of the content, which will happen with nested details as the HTML5 spec allows.

If the details node were to fire an event whenever the rendering was toggled, scripts could be attached to that event and we would not need to use polling or already deprecated events.

Real world scenario, some browsers may not provide proper accessibility to the details node. Adding a button element that adds/removes the open attribute solves this issue, but in order to keep the button text and title in sync with the details node it controls, the script to update the button node needs to be triggered by a change in the details node itself and not rely on the button being used.
Comment 1 Kang-Hao (Kenny) Lu 2012-01-06 14:34:51 UTC

*** This bug has been marked as a duplicate of bug 14101 ***
Comment 2 Kang-Hao (Kenny) Lu 2012-01-06 14:37:09 UTC
Feel free to reopen the bug if I misunderstood your proposal!
Comment 3 Michael A. Peters 2012-01-06 20:21:19 UTC
I think the duplicate assignment is correct, the other bug is exactly what I would like to see.