Description: ------------ The select id is not being generated. Test script: --------------- $form->addElement('date', 'inicio', 'Início:', array('language' => 'pt-br', 'format' => 'H:i', 'optionIncrement' => array('i' => 5))); Expected result: ---------------- Actual result: --------------

Hi Eduardo, thanks for the request. The problem here is that the QF date element is internally (in QF) a group with multiple select elements. My renderer handles single select elements as expected (i.e. with the id being added). Other groups are currently handled in the way that the label tag for the group does not get the "for" attribute. Therefore, why do you want to add the "id" attribute to the first select element of the the date group? My solution would be to remove the "for" attribute for date elements, like it is already done for normal groups. (If the date element would be handled like a normal group in QF, my renderer would already behave this way.) Please let me know what you think of this. Thanks, Mark

Hi Mark, The invalid id causes validation problems (XHTML 1.1 @ validator.w3.org). My first idea was to give consistency to this kind of label: clicking on it would put keyboard focus on the select element. Now I noticed that this doesn't happen in any popular web browser. Removing the "for" attribute would require the label to wrap the select element, which cannot wrap <div class="qfelement"> because that would mean a new lot of validation errors. My guess is that it would require some css and/or <div> rework to validate the page. Thank you for your attention. -- Eduardo Marinho

Hi Eduardo, > The invalid id causes validation problems (XHTML 1.1 @ > validator.w3.org). Yes, that's why I'm willing to change the behaviour of my renderer. But we need to find an agreement on how to do it. > My first idea was to give consistency to this kind of > label: clicking on it would put keyboard focus on the > select element. Now I noticed that this doesn't happen > in any popular web browser. Right, I had also tried it and saw that no browser had this functionality. Therefore, it made sense for me to remove the "for" attribute. > Removing the "for" attribute would require the label to > wrap the select element, which cannot wrap <div > class="qfelement"> because that would mean a new lot of > validation errors. My guess is that it would require some > css and/or <div> rework to validate the page. Hmm, I can't really follow you here. The "for" attribute is already removed (actually it isn't added) for groups, as you can see in my example code for check boxes and radio buttons. And the example page is validated without any error. Can you please elaborate where you see problems by doing the same for the date element? Maybe it's just my bad English that I didn't got your point in your last comment. Thanks, Mark

Hi Mark, I don't think it's YOUR bad english. :-) I'll say it in HTML: Citing : for = idref [CS] This attribute explicitly associates the label being defined with another control. When present, the value of this attribute must be the same as the value of the id attribute of some other control in the same document. When absent, the label being defined is associated with the element's contents.

Início:

00 23 : 00 55

Início:

00 23 : 00 55

Início: 00 23 : 00 55

Since we can't call the whole group a single element and give it a "for", the only other solution would be to add a "for" pointing to the first select element. But validation also complains about "[" in "inicio[H]" in the id, so you could change it to just "inicio", for example:

Início:

00 23 : 00 55

Thank you for reading. -- Eduardo Marinho

Eduardo, thanks for the extensive answer. Now I've got point. I'll be on vacation from tomorrow for one week. After that I will play a little bit with the validator, but it seems that your original idea (which is also the last solution in your last comment, i.e. <label for="inicio" ...>, <select name="inicio[H]" id="inicio">) seems to be the most reasonable one. More from me in about a week ... Thanks so far!

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. --- Again, sorry for the delay. A fix is now available in CVS. I'll wait with a new release until I get feedback from you about the request for the required note. Thanks for noting this bug!