The ID need only be unique to the request and it does not need to be repeatable for each request of the same page. It is simply a way for the browser to link the label to the check / radio button such that clicking the label will then trigger the button. They need to be unique because all IDs in an HTML page need to be unique. I believe the UUID package was used originally to ensure uniqueness no matter what the user might choose as their IDs.
I think this is of little concern though. At least in the current patch, the IDs are explicitly called autogen_X, which is very unlikely to clash with a naming scheme from a developer. I could be wrong, but them's the breaks. The reason they don't need to be the same with every request is because the developer has basically TOLD us they don't care about the ID. In other words, if the developer cared what the ID of the checkbox was (for CSS or Javascript), they would have passed us -id when creating the element, and we would use it. The only place this case comes up is when they are creating a check or radio button and they've basically said they don't care about the ID. But we do. The browser can't link the label to the button without the button having id="X" and the label having for="X". That's all this does. Pick up slack where the developer hasn't cared enough to uniquely name the element. If you care, name your element, but if you don't, we still need to do the right thing for usability and accessibility. I would probably just go with a class variable counter for the form package and increment it each time. Easy solution, the counter variable is obvious to anyone reading the form package, and the number will always be unique to the request even if they create multiple forms on a single page. Don't overcomplicate it. Them's my two cents. D On May 30, 2012, at 10:20 AM, Harald Oehlmann wrote: > Am 29.05.2012 17:26, schrieb Damon Courtney: >> ## If you don't mind creating a variable in the request namespace >> autogen_[incr ::request::__formElemCount] >> >> OR >> >> autogen_[info cmdcount] >> >> OR >> >> autogen_[clock microseconds] >> >> would all work just fine without the requirement of another package. > > Hi Damon, > > Refering to the issue to generate the value "idcur" of: > <label ref="idcur">labeltext</label><option id="idcur" name="namecur" > value="valuecur"/> > > I have another thought on your propositions how to replace the uuid package. > There are some solutions to generate the value "idcur": > S1) uuid package > S2) counter which starts with 1 at each http request > S3) [info cmdcount] > S4) [clock microseconds] > S5) interpreter wide counter > S6) form name + form internal counter > > Here are some thoughts: > T1) The id must be unique per http request result > T2) when requesting the same url, there should be the same answer. > T3) Two http requests should not be in any information relation. > T4) Don't expose any internals > > I am not shure about T3, but this feels as a potential security hole. > > Here is the judgement of the solutions and the thoughts: > > | T1 | T2 | T3 | T3 | > ---+----------+----------+----------+----------+ > S1 | yes | no | yes | yes | > S2 | yes | yes | yes | yes | > S3 | yes | no | no | no | > S4 | no | no | no | no | > S5 | yes | no | no | no | > S6 | yes | yes | yes | no | > > So, S2 fullfills all thoughts. > > S3 to S5 would give internal information of the interpreter to the > outside and put multiple requests in a relation (which request follows > which). As stated before, I am not shure if this is an issue but it > feels like a security hole. > > I prefer S6, as: > + it is easiest to implement (object variable) > + it is most logic to the outside > - it exposes the internal form name (so T3 fails). > Someone might have a better idea here. > The form name may not be in the character set of an id. > > Enjoy, > Harald --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
