Markdown issue: <details> collapse after an embedded task list item is checked off

Hey all. I sent this to GitHub support all the way back in May, but haven’t heard anything. Maybe I can try my luck here

I’m having this issue when checking off items on GitHub that are embedded inside of the details tag. To reproduce, create an issue with the following:

<details>
  <summary>some summary</summary>

  - [ ] item #1
  - [ ] item #2

</details>

Then expand the spoiler and check off an item. You will see the spoiler collapse.

Any ideas on how to fix that?

Hi there gordonel! :wave: Welcome to the Community!

Unfortunately I think this is expected behavior! Changing the state of a checkbox is making an edit to the comment, and for the edit to complete, the comment needs to refresh. As you can’t set a <details> section to load in the open state, upon refresh it’s closed again.

There would need to be a pretty big change in the behavior of either checkboxes or <details> blocks for this to work in the way you’d like.

We could make checkboxes only fully update if the comment is manually saved? This would likely result in people accidentally not checking intended boxes, as they may navigate away from the page before manually submitting the change.

Alternatively <details> sections could remember their state, so that once they’re opened, they stay open? Making the state unique to each user would be significantly more complex than having one general state, so I don’t know how likely that would be to get implemented. Having a general state would mean that once someone has opened the section, if they don’t close it themselves, it will load as open for the next person, which would kind of defeat the purpose those sections are usually used for.

We’re always working to improve GitHub and the GitHub Support Community, and we consider every suggestion we receive, so if you’d like to request either of these options, or a different change in behavior, would you mind submitting this through our official product feedback form so that our product team can track your request?

Thanks for getting back to me. The alternative solution sounds best, and we don’t really need for the state to be saved on per-user basis. The state can be reset to a default one after a user refreshes the page, for instance. It would also help if checkboxes reacted more quickly. Right now, there’s a lag a few seconds long

1 Like