I have a dynamic tree view checkbox list which works really well, but ideally I need it to work using expandable children when the parent is checked. Its a lot of code, and would be very grateful if someone who could a look and help me out.
So on load the two parent checkboxes are in view, and the children are hidden, then when one of the parents are clicked the children checkboxes appear and so on down the tree.
I think this is a bit simplistic and not fully tested but you could close and open the checkboxes with some css only.
e.g.
.custom-unchecked + ul {display:none}
.custom-checked + ul {display:block}
Of course once you click the main checkbox to open the children then they are all checked by default. I don’t see how you could do it otherwise without some other intermediate step or extra elements.
If that’s not what you meant I’ll leave the question for the JS experts 
Ye that does work to a certain extent Paul, and thanks also for helping. It definitely does the two highest parents, and when clicked opens up all the children to be viewable, I’ll check and see if this is good enough, but I think ideally I need to have it so checking the parent opens up the next parent whereby their children and hidden until that parent is clicked.
Yes I think you will need some js logic to do that
I’m not sure how you can handle the logic though because the way you have it set up is that when you check ‘food’ then it checks all the food items by default. If you want ‘food’ to only reveal the next level of checkboxes then you will lose that previous function as both can’t be true. i.e. you can’t select food and then show unchecked check boxes unless you make ‘food’ just a toggle(hide and show) and not a global selection of child checkboxes…
Catch22 almost.
Anyway this would be a job for a js programmer as my head hurts just thinking about it
Is this the sort of tree that you’re wanting?
Ye I see what you mean guys, what with the automatic checking of the boxes.
What I think the answer is that I create a plus a minus button, next to the buttons, and they control the children opening up and without checking the boxes at the same time.
Do you think that would work guys, and possibly an easier way to develop it rather than going back to the drawing board.
So in effect keeping it as it is now, with the Paul additions, but adding an extra open close option next to the options.
And the big cheeky question, would be grateful for help if you guys can
have updated the fiddle
It’s a start,its not right as I should get a no on the last children, but maybe its a starting point, to then add + and - buttons, and work on those, but if someone can help that will be great as I could be on this for hours/days when ideally i get it sorted sooner.
Thanks
Ok I have managed to push this on, and have got the + showing where they need to be.
Have added a clickable + sign, but what I need to do now is when its clicked or open it changes to a -.
And then changes back when its closed.
And ideally it only opens up the next set of children, and not open up all the tree
Have started a function and update the fiddle.
What I’m trying to do now is create a function that knows when its clicked that it needs to change from its state of + to a -, then on click again it changes from - to +.
Cant use toggle as I’m changing the html value of the span.
Hi,
The best I can do with mainly css is something like this.
I added html for the plus signs and a lot of logic with css. the only JS I added was to toggle the class for the plus signs.
The problems I see are that if the food checkbox is checked then you have to hide all the nested plus icons and show all the tree elements. If the food checkbox is an indeterminate state then again all the tree needs to be shown and not allowed to collapse elements otherwise you won;t know whats clicked.
That effectively means that sub items can only be opened and closed if the main checkbox has not been checked.
I can’t see any other way that the logic would work unless you also have an indicator to show that sub items have been checked or not.
The problem with messing about with form elements is that you lose the inbuilt accessibility features and keyboard selections. A lot of testing would need to be done to make this keyboard accessible in the same way that a straight forward form would be accessible.
I’m also sure that @Paul_Wilkins could simplify the JS logic and include the logic that I have put to the css at the same time.
Anyway it may help for you to experiment and see if this approach is worth pursuing
That is awesome, thanks Paul.
Like I said that would have taken me a few days at the rate I was going at.
Works perfectly thank you.
I’m in the middle of flu season, which is why I recommend that an existing working solution be used instead of what seems to be reinventing the wheel.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.