Roundup Tracker - Issues

Issue 1513369

classification
Title: input fields should have HTML id attributes
Type: rfe Severity: major
Components: Interface Versions: devel
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: tobias-herp Nosy List: ajaksu2, rouilj, tobias-herp
Priority: normal Keywords: patch

Created on 2006-06-27 14:01 by tobias-herp, last changed 2016-06-25 23:58 by rouilj.

Files
File name Uploaded Description Edit Remove
th_label.patch tobias-herp, 2006-08-11 18:18 macros th_label and th_label_required
templating.patch tobias-herp, 2006-08-15 18:00 changes to templating.py
user-labels.patch tobias-herp, 2006-08-15 18:27 adds the last missing label/id for user.item.html
Messages
msg3427 Author: [hidden] (tobias-herp) Date: 2006-06-27 14:01
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.
msg3428 Author: [hidden] (tobias-herp) Date: 2006-08-11 18:18
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.
msg3429 Author: [hidden] (tobias-herp) Date: 2006-08-12 06:05
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 ''"
msg3430 Author: [hidden] (tobias-herp) Date: 2006-08-15 18:00
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)
msg3431 Author: [hidden] (tobias-herp) Date: 2006-08-15 18:27
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.
msg3432 Author: [hidden] (tobias-herp) Date: 2006-09-18 01:32
Logged In: YES 
user_id=805804

updated templating.py; the input method takes care of
missing type and id attributes of <input> elements
msg5624 Author: [hidden] (rouilj) Date: 2016-06-25 22:39
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
msg5625 Author: [hidden] (rouilj) Date: 2016-06-25 23:58
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,
History
Date User Action Args
2016-06-25 23:58:36rouiljsetmessages: + msg5625
2016-06-25 22:41:11rouiljsetkeywords: + patch, - jinja2
2016-06-25 22:39:51rouiljsetkeywords: + jinja2, - patch
nosy: + rouilj
messages: + msg5624
severity: normal -> major
versions: + devel
2016-04-11 00:52:37rouiljsetkeywords: + patch
nosy: + tobias-herp, - tobias-herp
2009-02-20 02:04:43ajaksu2setnosy: + ajaksu2
2006-06-27 14:01:31tobias-herpcreate