Re: User interaction and details element

You obviously already created an issue for this earlier:

https://github.com/w3c/html/issues/600

I think it's better to continue the discussion there. But I agree that
this behavior should be changed.

Sebastian

On 13 October 2016 at 10:41, Andrea Rendine
<master.skywalker.88@gmail.com> wrote:
> 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 12:25:05 UTC