While I found a workaround to make "for" attribute of labels to have the same value as input ID, this workaround is not working if the form is inside a pop-up (bootstrap modal dialog) or inside a bootstrap tab.
In fact, even if I use default styling, the "for" attribute takes some random value.
Besides, it not only messes up the fields built with the Toolset, but also the fields I added into the form manually. It replaces the "for" I specified for the label in php with a random value.
Please test it on your side and confirm (or not) the issue.
I assigned this Ticket to Shane since you requested his help.
I think we have internally something filed for it, and I already gave Shane a Hint on the internal issue tracker.
If that reported issue/request does not exactly match your issue, Shane will debug this with you and either file a Feature Request or a BUG Report.
I just wanted to let you know that CRED uses a lot of "random" values.
In ID's and other attributes.
Those change either per-form or even each time you load a form.
This is due to the uniqueness of each form/Field.
If we would not do that, fields and posts can get overwritten.
This is of course not related to the "for" attribute, but it is for the ID of several things.
And that we cannot easily change.
It seems that there was a feature request opened for this and a document shared. I've requested permissions to view this document and will let you know if the request was added or not.
Thanks for the update. The good news is that the site is still in development, so I have time to wait for the fix. At the same time, remembering my last request, it took you guys 1.5 months to give some news, so I hope this is not going to be the same case.
I've got a reminder from your cleanup robot this morning (4 times for some reason) to update this thread.
The issue is still very hot and I'm looking forward to hearing your good news about it as it affects almost a half of the sites I've built with Toolset.
I can confirm that it has been added to our list of CRED requests and waiting for the appropriate steps to be taken for this to be discussed with our development team.
There's not much in news I can provide after the feature request has been added to our list since it is out of my hands whether it will be added or not.
I can only give information when the status of the request is approved.
In order for my ticket not to get closed automatically while I'm waiting for the solution, I guess it makes sense if you don't reply to this message and it does not take status "Waiting for user confirmation". Please reply only if you have any news.
The issue is that the ticket cannot sit idle in the queue 🙁
Usually once a feature request has been made and the customer is informed that this request has been made then there really isn't anything else that we as support can do but to inform of the request.