- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 22 Aug 2008 07:15:17 +0000 (UTC)
- To: Mihai Sucan <mihai.sucan@gmail.com>
- Cc: public-html <public-html@w3.org>
On Sat, 8 Sep 2007, Mihai Sucan wrote: > > "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. Ok. > 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 > closed. > > 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. I agree with your use case, but with the current definition the author can actually work around the lack of an event using mutation events to watch the attribute. I'm going to punt on defining explicit onopen/onclose events for now, at least until mutation events are better defined and integrated with the event loop. If we find that they would indeed be useful, we can add them later without difficulty. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 22 August 2008 07:15:37 UTC