Re-imagining details/summary design


Yes i cannot but agree. I think the issue is exacerbated by trying to put too much UI under UA control. In future we should be striving to implement functionality with a minimum of UI where possible and leaving the design layer to developers.


The modal stuff seems to gone the same path.

Its still frustrating theres no way to have a basic popup menu today without some sort of JS.

I wish some more primitive stateful (but not form specific) controls could be exposed. If you could just have a simple “togglable button” element that had built in state, you could implement menus and disclosures all built on css state queries.

details {
  display: none;
button:on ~ details { // whatever generic psuedo state
  display: block;


Yeah, this is exactly what I was saying above… There are some proposals/discussions already that attempted to explore how you might move this into CSS and, for example, but it does seem that this is part of the semantics of what you’re describing… I’d like to discuss/work on how you might be able to change that to solve all of the use cases (or at least more than just a simple summary/detail) that deal with toggling states of content. That seems like a more interesting sort of path to pursue…


Ha, sorry I missed that. Yeah, :+1: to all of it.


@briankardell Did I hear you say you were starting a repo with use cases and proposals for the toggle thing? :angel:


Already got a repo for toggling -


@tabatkins, clearly I supported this rationale a while ago, but I think that @SteveF is making a fairly solid point that this is semantics with respect to accessibility… Especially as we get into building up semantics from the community level and can actually convey useful things about the UI through tags, I’m wondering if it makes sense to handle those sorts of use-cases with CSS or not… Would you suggest that CSS is conveying semantics at that point?


CSS is not conveying the required semantics unless the control for toggling the content is exposing name, role, properties and states via an accessibility API.


Right, currently that is not the case - I am specifically asking whether @tabatkins is considering this and - I don’t know, still thinks it is a good idea or maybe wants to suggest that it should? I


The Toggle States draft allows for far more than just toggling the display of an element, though that’s certainly one common thing it’ll be used for. There’s no capacity for simple automatic accessibility mapping, any more than there is for some JS that increments a custom attribute on an element whenever you click a button.

If you want to communicate some accessibility information, it has to be done separately.


What advantages does the toggle states concept have over the disclosure button concept?


Vastly more general and more powerful.


Ashame it’s vastly less accessible, is there anything that can be done about building accessibility support in?


As I explained, getting the accessibility you want requires limiting it to a tiny subset of functionality, which isn’t feasible. It needs to be done via a side-channel instead. The Toggle States CSS is basically just an easier variant of using JS to increment an attribute on an element.


OK, so the scope of the disclosure button custom element and your CSS toggle stuff are very different and serve different purposes. It is probably better to view the disclosure button as an improved, more powerful version of details/summary as that is the design pattern it seeks to extend.