Changing label style in some widgets RE: 4860

30 views
Skip to first unread message

Sandro

unread,
Dec 5, 2007, 10:30:52 AM12/5/07
to Django developers
I'd like to start a discussion that branches off of ticket 4860. There
are a few django widgets (RadioSelect, CheckboxSelectMultiple,
others?) which produce html that has an input nested inside a label.
As Ivan pointed out, this is valid html but it just doesn't sit right
with me as I always code labels to be separate elements with only a
text node inside.

Right now, django produces:
<li><label for="id_language_0"><input type="radio" id="id_language_0"
value="P" name="language" /> Python</label></li>

All of my css research and experience uses this arrangement:
<li><input type="radio" id="id_language_0" value="P" name="language" /
> <label for="id_language_0">Python</label></li>

webstandards.org talks about using labels to make forms more
accessible and their examples never use an input as a child of a
label:
http://www.webstandards.org/learn/tutorials/accessible-forms/intermediate/

Is there any reason why django takes one approach and not the other?

Ivan Sagalaev

unread,
Dec 5, 2007, 10:37:02 AM12/5/07
to django-d...@googlegroups.com
Sandro wrote:
> Right now, django produces:
> <li><label for="id_language_0"><input type="radio" id="id_language_0"
> value="P" name="language" /> Python</label></li>

Not related to the discussion but for the accuracy's sake I'd like to
note that right now Django produces <label> without for=".." at all
which this bug is about.

Patryk Zawadzki

unread,
Dec 5, 2007, 10:44:29 AM12/5/07
to django-d...@googlegroups.com
2007/12/5, Sandro <sandro....@gmail.com>:

> I'd like to start a discussion that branches off of ticket 4860. There
> are a few django widgets (RadioSelect, CheckboxSelectMultiple,
> others?) which produce html that has an input nested inside a label.
> As Ivan pointed out, this is valid html but it just doesn't sit right
> with me as I always code labels to be separate elements with only a
> text node inside.
>
> Right now, django produces:
> <li><label for="id_language_0"><input type="radio" id="id_language_0"
> value="P" name="language" /> Python</label></li>

Which is correct and desired. If not Internet Explorer, even for="..."
and id="..." wouldn't be needed (and it's not there with current
Django).

IE is the only browser that can't match a label with the contained
input field and also the only one that needs for="..." in this case.

> All of my css research and experience uses this arrangement:
> <li><input type="radio" id="id_language_0" value="P" name="language" /
> > <label for="id_language_0">Python</label></li>

Which is also correct but slightly less desired.

So please count me as -1.

--
Patryk Zawadzki
PLD Linux Distribution

Ivan Sagalaev

unread,
Dec 5, 2007, 11:23:31 AM12/5/07
to django-d...@googlegroups.com
Patryk Zawadzki wrote:
> Which is correct and desired. If not Internet Explorer, even for="..."
> and id="..." wouldn't be needed (and it's not there with current
> Django).

BTW, in current Django presence of for and id should be controlled by an
auto_id parameter of a form. However RadioSelect and
CheckboxSelectMultiple are the only controls that don't respect it on
labels.

Malcolm Tredinnick

unread,
Dec 7, 2007, 3:15:45 AM12/7/07
to django-d...@googlegroups.com

Okay, I think my brain just melted trying to follow the various
sub-problems mentioned here. Can somebody make sure that whatever issues
are brought up here are turned into tickets, if they don't already
exist? This thread has become a maze of twisty passages, all alike, in
only four messages. It can only get worse. :-(

Thanks,
Malcolm

--
Depression is merely anger without enthusiasm.
http://www.pointy-stick.com/blog/

Ivan Sagalaev

unread,
Dec 7, 2007, 7:57:49 AM12/7/07
to django-d...@googlegroups.com
Malcolm Tredinnick wrote:
> Okay, I think my brain just melted trying to follow the various
> sub-problems mentioned here. Can somebody make sure that whatever issues
> are brought up here are turned into tickets,

I'll try to clarify since it looks that I'm responsible for most of the
confusion.

1. There is a bug: RadioInput and CheckboxSelectMultiple don't respect
auto_id setting, they always output labels without "for":

<li><label><input ... id="some_0"></label></li>

2. Ticket 4860 exists to fix this bug. It has two patches both fixing
the problem but in different ways:

- one (ca2.diff) makes output like this:

<li><input ... id="some_0"><label for="some_0"></label></li>

- another (4860.diff) retains <input> inside <label>:

<li><label for="some_0"><input ... id="some_0"></label></li>

The latter patch is mine and my reasoning behind this is simply
consistency: Django wraps <label> around <input> everywhere.

3. This thread was started by the author of the first patch to discuss
whether Django should or should not wrap <label>s around <input>s in
general. This is a more general question that was inspired by but is not
related to the ticket.

Sandro

unread,
Dec 7, 2007, 1:50:54 PM12/7/07
to Django developers
Actually, all of the patches I submitted need to be deleted. My
patches exhibit a certain html style (which this thread aims to
discuss) but my patches don't add the 'id' attribute which makes them
incorrect. Ivan's patch seems to solve the IE rendering problem and
maintains consistency with the RadioSelect widget.

If you pour through the tests/regressiontests/forms/forms.py file
searching for 'label' or 'label for=' you'll find that two different
styles exist:

<label for="some_id">Name: </label><input id="some_Id"... />
and
<label><input ... /> Name:</label>

I'm trying to figure out whether these two styles is an inconsistency
and a bug or if they were intended.

gke...@gmail.com

unread,
Dec 11, 2007, 2:03:14 PM12/11/07
to Django developers
From
http://www.w3.org/TR/html4/interact/forms.html#edef-LABEL
"for: 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."

So both styles are technically correct. There is an allowed
flexibility by using "for" for inputs which cannot be wrapped in a
label, like if the label and input are in different table cells.
Reply all
Reply to author
Forward
0 new messages