Every generated INPUT field (at least the non-hidden
ones), SELECT tag or TEXTAREA should get an ID
attribute; this would allow to use <label
for="{id}">...</label>.

For every input type except radio and checkbox, which
commonly occur more than once with the same name, this
could be the same as NAME by default.

Logged In: YES 
user_id=805804

The benefit of HTML labels is creating a connection between
the input field and its description; e.g. when clicked on
the label, a graphical browser puts the focus to the
labelled input field (or select or textarea). A checkbox or
radio button would be selected. Labels are likely to be used
by special browsers for handicapped persons, too.

My patch introduces the macros th_label and
th_label_required (named to reflect the fact they create a
th tag with a label inside). They play nicely with i18n.

The main use case is the issue.search.html template; the
search input macros have been updated, too, to make the
labels work (an id attribute is needed).

For the fields in issue.item.html, there is no visible
effect yet because the methods used there don't create id
attributes (yet); but you get the idea.

Logged In: YES 
user_id=805804

I'll drop the th_label_required macro in my patch for
request 1539081; th_label can handle it like this:

... tal:attributes="class python:(name in required) and
'required' or ''"

Logged In: YES 
user_id=805804

Patch: create id attribute for a lot of input and select
tags (I might have missed some, but e.g. in user.item.html,
all fields would get one)

Logged In: YES 
user_id=805804

This patch (when applied after user-defaults.patch/issue
1539080) adds the last missing label/id in user.item.html,
making clicking to the label work for all input fields.

For alternate_addresses, I didn't get it how to hand over
the label text (containing the <br> tag) in a way yielding
the desired effect, so I didn't use the th_label macro there.

Logged In: YES 
user_id=805804

updated templating.py; the input method takes care of
missing type and id attributes of <input> elements

I like the idea behind the patch. I think having id's should be
required. However with this patch, what happens if the same field is
referenced in multiple forms on the page?

IIUC that breaks things,( id must be unique on the page) so we need a
way to disable the addition of id's or allow the template designer to
pass (or remove) the id field when calling the templating function.
Maybe set a default id and allow passing a different value in if the
field is used a more than once will work.

Also consider an index page where every row has editable fields, E.G.
bulk updates. So you get an id=title from issue1, issue2 etc.
Using an id that depends on the issue number works for this case, but
not if the same field for the same issue is reused on a page.

I thought there was a way via python:....field(id="field") and menu()
etc, that unknown arguments were passed through to the underlying
rendered HTML. Can't find the reference and I don't have the code
available at the moment.

--rouilj

After getting to some code, it looks like id's added using:

  kwargs.setdefault("id", self._formname)

will let the template creator override using

  .../field(id=mumble)

but it looks like there are some id's in the patch that can't be overridden.

So this may need a little work,