-
-
Notifications
You must be signed in to change notification settings - Fork 557
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
Feat/toggle checklist groups #1280
base: main
Are you sure you want to change the base?
Feat/toggle checklist groups #1280
Conversation
Thank you for opening this Pull Request! Please make sure you've read our Code of Conduct and Contributing guidelines. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me! Thank you for submitting it, @rachel-fischoff.
@SaptakS: Could I get a second set of eyes on the JS?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Accidentally created this review without code comments. Please refer to #1280 (review)
src/js/checklist.js
Outdated
|
||
renderToggleAll(); | ||
|
||
function renderToggleCategories(){ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🔍 You can probably write a query selector that gets both #toggle-all
and all the other buttons, which then means you won't need a dedicated function for renderToggleAll
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for writing this PR, @rachel-fischoff, and thank you for your patience with our reviews! Your code looks great! I would like to take care of some things that were not in #940, but which I consider to be blocking.
Issues
- These new toggle buttons are not very helpful without JavaScript, so IMO they should be hidden initially, and then shown once we can confirm that JavaScript is on the page.
- These new buttons need styling in general, so they look like they fit in with our existing design and layout.
- IMO, if the checklist items in a category are not all in the same open state, we should either open all of them or close all of them.
Expanding (ha) issue number 3:
Say the user opens "Use plain language..." to expand it so only that item is open while all the others are closed. Then the user clicks "Toggle Content".
- Current behavior: All of the items in the category flip states. "Use plain language..." is closed; all the others open
- Desired behavior: All of the items in the category are opened or closed.
Next steps
- Decide how we ship this. Do we improve the style of the buttons, ship the feature, then come back and improve the open/close state management, or do we do all of this in one PR?
- Decide what to do in the case of mixed states.
- In the case of mixed states, like above, what should the next state be – open, or closed?
- How will we handle the
Toggle all
button if one or more items in any category is open?
Thoughts, @ericwbailey and @rachel-fischoff?
Hi @rachel-fischoff! First off I want to apologize for the delay in responding to this. I've been going through a ton of work-related things and it's taken a lot of time I'd normally have for work here. This is going to be a very welcome addition to the site, and I'm really happy you did the work. For my perspective on @mxmason's questions:
For styling, I'm very familiar with this site's Sass, so I was figuring I could create a followup styling PR once the logic is done/ As for the logic, I think we should get it into the desired state in this PR.
My thinking here is: Toggle all:
Toggle section:
I am modeling my thinking here after similar OS UI behavior in terms of external consistency (I'm thinking file trees and similar kinds of interactive nested list content). The other thing that I think is tangentially relevant is toggle states and accessible names. I don't think this is relevant here directly, in that the existing accessible name plus the ARIA we're using should be sufficient? |
Thank you @mxmason & @ericwbailey for this very thorough feedback! I will get to work on the changes early next week! I'll check in if I have any additional questions! |
Yes! Really looking forward to it 🙂 |
…gories to one function
@mxmason & @ericwbailey Hey y'all! I finally finished the functionality! I'm ready for styling help. Thanks for your patience. Let me know if you have questions or comments. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works great! Added few knitpicking comments. There also seems to be some merge conflict issues that got into the package-lock.json file. Apart from that, I guess @ericwbailey we need some designs to match the rest of the style of the website.
I know this is almost 2 years old but should I close this PR @mxmason @ericwbailey or should I still try to get this functionality merged in? Not sure if it's even desired anymore. |
I think @ericwbailey might be able to comment better, but I would definitely love to see this PR merged given you still have the capacity. I can do a re-review to see if all the above concerns are addressed and what is left if that helps. I think @ericwbailey said he can make a commit for the design separately once functionality is done. In case he is not available, I can use existing designs in the sass code to make it look similar to the rest of the website. |
@SaptakS I think I had addressed all the comments beforehand and was hading to hear back. If I recall, I was just waiting on the design but let me know about functionality. I can also update with the latest main. |
I will take a look. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code seems to be not functioning right now. I left a few comments which I think should help resolve that. Also, @mxmason mentioned that we should hide the toggle buttons by default and only show them from the javascript code, because the toggle buttons don't work without javascript, and hence shouldn't be visible for non-js users.
registerToggleButton(toggleAllButton, document); | ||
|
||
var toggleCategoryButtons = document.querySelectorAll( | ||
"[data-toggle-category]" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this selector is not working anymore because the njk code no longer has this data attribute. Probably can use .toggle-category
instead? I think because of this the category toggles are not working anymore.
buttonEl.addEventListener("click", function handleToggleButtonClick(event) { | ||
var target = event.target; | ||
if (target.hasAttribute("data-open") === true) { | ||
target.removeAttribute("data-open"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we instead use aria-expanded="true"
in place of data-open? I think that will help convey meaningful information to the assistive technology about the state of the button as well, and helps with the logic as well.
For reference: https://adrianroselli.com/2020/05/disclosure-widgets.html#Script
|
||
function registerToggleButton(buttonEl, parentEl) { | ||
if (buttonEl && parentEl) { | ||
var details = parentEl.querySelectorAll("details"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make this selector a little more specific? Like details.c-checklist
to ensure that we are not toggle any other <details>
that might be there. Just to future-proof it a bit.
@SaptakS will address this weekend and get back to you! |
@SaptakS Sorry, I've been sick but I'll message you when I have the fix. |
@rachel-fischoff no need of apologies and no hurries. Take your time! And I hope you feel better soon. |
Hi @SaptakS and team. I keep overestimating my capacity and haven't been in JavaScript land in a long time. I think it makes the most sense to just close this PR and then comment on the issue that I never got around to it. If someone wants to open it back up or continue this work then they are more than welcome. |
That's totally fine! I don't think this PR needs to be closed. Especially since it doesn't have any merge conflicts. I think anyone (or one of us) who wants to work on the issue can continue on this PR. I haven't checked however if this branch can be pushed into by us. If not, I might create a new PR with your commits and continue from there. But I don't want to close this PR and make your work go away. :) Thanks for your contributions! |
closes #940
Summary
Creates a Toggle Button for each section of the Checklist (toggle content, toggle keyboard, etc) that allows you to mass open or close all of the details for each section. Additoinally, a toggle all button is created to expand and collapse all the checklist group items on the entire Checklist page.
Images
Below is the Toggle Content before being clicked
Below is the Toggle Content after being clicked and expanded
Below is the Toggle All button located above the first checklist group
Next Steps
Would love to get some input on the styling especially for the Toggle All button!