W3C home > Mailing lists > Public > public-html@w3.org > September 2007

Detailed review of 3.18.1 The details element

From: Mihai Sucan <mihai.sucan@gmail.com>
Date: Sat, 08 Sep 2007 19:57:20 +0300
To: public-html <public-html@w3.org>
Message-ID: <op.tychduw2mcpsjgr0b0dp@athlon>


I have reviewed 3.18.1. "The details element" definition in the HTML 5  
specification [1]. I have the following comments to make:

1. The elemenet is nicely defined, while allowing a dynamic legend for the  
content of the details element. The provided solution, having <legend> as  
the first element, is an elegant solution to the problem discussed on the  
GNOME Usability mailing list [2].

"Kudos" to Hixie.

2. "Big Issue: Clicking the legend would make it open/close (and would  
change the content attribute). Question: Do we want the content attribute  
to reflect the actual state like this? I think we do, the DOM not  
reflecting state has been a pain in the neck before. But is it  
semantically ok?"

Personally, I believe that the content attribute needs to reflect the DOM  
state. Semantically this is correct, because it represents the actual  
state of the DOM when some script wants to serialize the DOM. I wouldn't  
expect the UA to give me something different.

3. I have a suggestion: add two events.

"When the open attribute is toggled between the true/false values, the  
user agent must:

1. fire the open event on the details element, if the new value is true;
2. fire the close event on the details element, if the new value is false."

Maybe a better possibility would be to just fire the "change" (or  
"toggle"?) event in both cases: when the <details> element is opened or  

Scripts will need to act upon opening/closing the <details> elements.

Use case: given a big form, with lots of possible values in some  
drop-downs, a Web page might be optimized to not automatically load all  
the form values, which are not visible by default, in closed <details>  
elements. Upon opening the <details> elements, the script can  
automatically load any remaining data, can enable certain inputs, or do  
anything else required by the specific situation.


[2] http://mail.gnome.org/archives/usability/2006-June/msg00015.html
     The link can be found within the HTML 5 specification source, see the  
comments in "The details element" section.

Received on Saturday, 8 September 2007 16:57:38 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:21 UTC