- From: Andrea Rendine <master.skywalker.88@gmail.com>
- Date: Thu, 13 Oct 2016 10:41:11 +0200
- To: "public-html@w3.org LIST" <public-html@w3.org>
- Message-ID: <CAGxST9=FP0JoQ1SdTjavO7tcbqiwXJ6J0JTco9-mqSCrxPo8iA@mail.gmail.com>
There's something I don't understand about the <details> element, I hope this is the right place to ask because it could also be fixed in the future. The spec says, and it's a behaviour commonly honored by UAs supporting the detailselement, that the "open" boolean attribute is to be set or removed when users click on the summary element. As far as I know there aren't many situations where user interaction actually changes the DOM. Namely, when users click on checkboxes, the control state changes but no "checked" attribute is set on the element itself, though the checked IDL property changes (of course this is valid for all of the form controls, but checkboxes and radio buttons are closer to this case as checked is boolean). This is valid for newer tags, too. Visual UAs are expected to show a control bar for <video> elements when the controls attribute is present. This bar can also contain a volume control with the option to mute the video. But the spec does not say that UAs have to change the "muted" attribute, also because its presence defines the state of the defaultMuted IDL property. Of course nothing bad can derive from this, but it's a sort of inconsistency. If it's just a matter of CSS, it would be more consistent to have an ":open" pseudo-class for it, corresponding to the open state. And I cannot believe it hasn't been done for legacy issues, because nobody stood against new pseudo-classes like ":required", ":valid" and so on.
Received on Thursday, 13 October 2016 08:41:41 UTC