using for with labels and checkboxes in repeating sections

How do you address the id of a html element inside a repeating section? For example, here's a simplified version of using for from the wiki article on CSE: < input id = "mod" name = "attr_mod" type = "checkbox" value = "1" > < label for = "mod" > Checked? < /label > When this is outside a repeating section, you see correct behaviour: if you click the label , the checkbox is clicked or unclicked. What's the syntax for this to work inside a repeating section? Prepending the repeating section doesnt work (and where would you assign it?). The only way I've found so far is the old nesting method: < label > Checked?      < input name = "attr_mod" type = "checkbox" value = "1" > < /label >

Addendum: I know ids have to be unique, and am operating on the assumption that roll20 somehow integrates them with repeating sections, the way they append section name and row id to attribute names, but it may be that ids are completely incompatible with repeating sections under the current implementation. I'd like to know one way or another.

So this is the problem: When you create a repeating section, the HTML you define it with stays in the sheet. So, since an id selector expects only one target, it's always going to find this hidden one before it gets to the actual repeating container. Un-hiding the repeating template HTML shows this working - clicking on any of your repeating section labels will select that (normally hidden) template input. So yeah, ids are no good in repeating sections unless Roll20 adds some live, dynamic processing on them to either index them or add the row id, or something like that. Is there much use for that apart from <label> elements? CSS obviously has plenty of other selectors to use.

Oosh said: So yeah, ids are no good in repeating sections unless Roll20 adds some live, dynamic processing on them to either index them or add the row id, or something like that. Is there much use for that apart from <label> elements? CSS obviously has plenty of other selectors to use. I don't know if IDs are needed for this, but the jQuery-like stuff is pretty much useless in repeating sections, for things like CRP, because we need the row ID to capture all the information.  So, I think it's useful for more than just labels; it would also be useful for adding classes, because right now, it adds the class to every row in a repeating section.

Oosh said: So yeah, ids are no good in repeating sections unless Roll20 adds some live, dynamic processing on them to either index them or add the row id, or something like that. Is there much use for that apart from <label> elements? CSS obviously has plenty of other selectors to use. Roll20 made a big thing of supporting some jQuery features, with the intention of expanding it to include more. But that depends on ids, and with ids not usable in repeating sections, it means none of the jQuery features will work there. That's a pretty big deal to me. The for with labels discovery was me just starting to explore what can be done with the new jQuery features, and I hit a snag immediately :)

Yep, unfortunately ids cannot be used in repeating sections because they are the same for all rows. And the jQuery stuff is pretty much only usable as an alternative way to implement tabs or sheet popups.

I was going to suggest making your own label out of a span and an almost-jQuery handler. But there's no focus() exposed, and then there's this: The contents of individual repeating items can't be targeted or reacted to So.... I guess that's that, then? :)

Scott C. said: Yep, unfortunately ids cannot be used in repeating sections because they are the same for all rows. And the jQuery stuff is pretty much only usable as an alternative way to implement tabs or sheet popups. It's limited now, but the original announcement suggests they had or have plans for more features for it. 

GiGs said: Scott C. said: Yep, unfortunately ids cannot be used in repeating sections because they are the same for all rows. And the jQuery stuff is pretty much only usable as an alternative way to implement tabs or sheet popups. It's limited now, but the original announcement suggests they had or have plans for more features for it.  Not to crush your hopes up, but their wiki had mentioned more card support for the API and the such, but it took literal YEARS for anything to make movement there... :-/

Finderski said: Not to crush your hopes up, but their wiki had mentioned more card support for the API and the such, but it took literal YEARS for anything to make movement there... :-/ Haha, I did restrain myself from making any comment about the timeliness of future features.

GiGs said: Haha, I did restrain myself from making any comment about the timeliness of future features. LOL That's because you're a better person than I am. :)