W3C home > Mailing lists > Public > public-html@w3.org > January 2012

[Bug 15438] New: Details node needs to fire event when opened or closed

From: <bugzilla@jessica.w3.org>
Date: Fri, 06 Jan 2012 05:56:25 +0000
To: public-html@w3.org
Message-ID: <bug-15438-2495@http.www.w3.org/Bugs/Public/>

           Summary: Details node needs to fire event when opened or closed
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: mpeters@domblogger.net
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,

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

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.

Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Friday, 6 January 2012 05:57:17 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:19 UTC