The usage is much more convienient if one can click on the label instead of the small radiobutton/checkbox.

Other files which contain "radio" or "checkbox": account/prefs/email.html.tmpl attachment/create.html.tmpl attachment/edit.html.tmpl bug/dependency-graph.html.tmpl bug/create/create.html.tmpl bug/process/confirm-duplicate.html.tmpl bug/process/verify-new-product.html.tmpl bug/votes/delete-all.html.tmpl bug/votes/list-for-user.html.tmpl list/change-columns.html.tmpl list/edit-multiple.html.tmpl list/table.html.tmpl reports/duplicates.html.tmpl search/form.html.tmpl search/knob.html.tmpl

Implementational note: I used <label for=""> instead of the implicit <label> usage since IE has problem with this (if I recall correctly, I have at the momemnt no IE to test).

Comment on attachment 91383 [details] [diff] [review] v1: Patch bugs/edit.html.tmpl only >+ <input type="radio" name="knob" id="knob-resolve" value="resolve"> >+ <label for="knob-resolve"> >+ Resolve bug, changing <a href="bug_status.html">resolution</a> to >+ <select name="resolution" >+ onchange="document.changeform.knob[[% knum %]].checked=true"> >+ [% FOREACH r = resolution %] >+ <option value="[% r FILTER html %]">[% r FILTER html %]</option> >+ [% END %] >+ </select> >+ </label> > <br> Are <label for="..."> with other form elements inside them likely to cause problems?

>Implementational note: I used <label for=""> instead of the implicit <label> >usage since IE has problem with this (if I recall correctly, I have at the >momemnt no IE to test). Confirmed. According to my tests, implicit label syntax doesn't work on IE up to versions 5.5. I'll test 6.0 later today.

>Are <label for="..."> with other form elements inside them likely to cause >problems? Couldn't say. Doesn't look like it, but OTOH there's no need to use ambiguous syntax elements when we've got two sane and clean alternatives as well (even though the other one of them doesn't work properly on IE). btw, filed bug 157692 on converting the existing containing-label-syntaxed things to the for-using model.

Isn't this a dup of 14887?

> Are <label for="..."> with other form elements inside them likely to cause > problems? I don't think they are, but it is cleaner without. (Fixed.) > btw, filed bug 157692 on converting the existing containing-label-syntaxed > things to the for-using model. The only place where grep could find such a <label> was actually in bug/edit.html.tmpl. (Fixed in this patch.) > Isn't this a dup of 14887? Yes it actually is. (searching for <label> I constantly wondered why there are two such similar bugs - not even realizing that I filled the duplicate :-( The patch I appended does: - add <label> to the radio + checkboxes - fix bug 157692 - add <label> to <select> comboboxes The latter I did accidently, but it is valid HTML 4.01 even if Mozilla doesn't support it (it ignores it for input type="text" and for <select>) This was actually already present: this was the usage for the only implicit <label> I found.

Comment on attachment 93464 [details] [diff] [review] v2: Patch bugs/edit.html.tmpl + fix bug 157692 Can someone test this on IE? Is the accessky really meant to be on the label, rather than the form element?

> Is the accessky really meant to be on the label, rather than the form element? It actually shouldn't matter, see http://www.w3.org/TR/html401/interact/forms.html#adef-accesskey and works using the Mozilla browser e.g. with the Bugzilla-2.17 query.cgi page.

> - add <label> to <select> comboboxes. The latter I did accidently, but it is > valid HTML 4.01 even if Mozilla doesn't support it. Well, actually Mozilla supports it (bug 28657). I therefore converted also the labels of <input type="text"> to use <label>. Otherwise unchanged.

Is it really a point dropping the 'for="field_id"' when using it makes <label> work properly in all browsers with all types of fields? I can't say I see one single reason for not using the 'for'-attribute.

Per comment 7, marking as a duplicate. *** This bug has been marked as a duplicate of 14887 ***