Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

<summary for> pointing to a <details> element elsewhere #818

Open
LeaVerou opened this issue Aug 25, 2023 · 6 comments
Open

<summary for> pointing to a <details> element elsewhere #818

LeaVerou opened this issue Aug 25, 2023 · 6 comments

Comments

@LeaVerou
Copy link

Since we're on to making simple improvements to <details>, how about this: a for attribute on <summary> which can point to a <details> element by id, allowing them to be in entirely separate parts of the DOM. This would address the common author need to have toggles in separate places from the toggled content, is pretty straightforward in terms of syntax, and follows established markup patterns.

@LeaVerou LeaVerou changed the title Allowing <details> and <summary> to be in separate places in the markup <summary for> pointing to a <details> element elsewhere Aug 25, 2023
@LeaVerou LeaVerou changed the title <summary for> pointing to a <details> element elsewhere <summary for> pointing to a <details> element elsewhere Aug 25, 2023
@lukewarlow
Copy link
Collaborator

Not saying this is better but a potential alternative to using for would be to use invokertarget from whatwg/html#9625

@YummyBacon5
Copy link
Contributor

This just seems like a collapse/expand button to show arbitrary content, rather than as an accordion. Meaning that authors would probably misuse this.

Also, even with custom versions of an accordion, the button which expands the accordion is always close to the expanded text. So I don't think that this is needed.

@dbaron
Copy link
Collaborator

dbaron commented Aug 29, 2023

I think it's worth considering whether #812 (comment) by @aardrian applies here as well; I suspect it does, though I'm not sure.

@scottaohara
Copy link
Collaborator

scottaohara commented Aug 29, 2023

i could see this getting rather messy with details/summary specifically, especially regarding the fact that a details will automatically insert a summary within it if an author has not specified one. (there's a rabbit hole of what ifs related to this)

Not opposed to the idea of having a control that can toggle the visibility of other content in the page, re: #700 and the linked WHATWG issue that Luke referenced. But I'd definitely think those are the way forward here, rather than extending the summary element further - esp. with the accessibility issues that still need to be worked out with that element, and how this would just add onto that existing todo list.

@aardrian
Copy link

My gut reaction here, before even getting into how to handle missing <summary> in the case of typos / errors, is focus and reading order management. These elements are useful because they do not require the author to do that and this model would need to address that in detail with rules for failures to do so.

Wrapper element already fits existing patterns.

Copy link

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

@github-actions github-actions bot added the stale label Feb 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants