Opened 13 years ago

Closed 9 years ago

#9079 closed New feature (wontfix)

Label tag attributes

Reported by: oggy Owned by: nobody
Component: Forms Version: 1.0
Severity: Normal Keywords: form label label_tag
Cc: Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Add the label_tag_attrs parameter to the Field init, to provide a convenient way of adding, say 'class="required"' to the generated label tag.

Attachments (1)

label_tag_r9027.diff (1.9 KB) - added by oggy 13 years ago.

Download all attachments as: .zip

Change History (8)

Changed 13 years ago by oggy

Attachment: label_tag_r9027.diff added

comment:1 Changed 13 years ago by Adrian Holovaty

Hmm, this seems a bit crufty. I'm inclined to favor a more generic approach to editing the HTML, like Simon Willison's template tag library.

comment:2 Changed 13 years ago by oggy

I gave a more detailed rationale for this in this django-dev post:

As always, there are some other takes on the issue there. Anyhow here's the crux of my argument:

  • there's currently no provision for adding any attributes to automatically generated label tags. This includes, but is not limited to the "class" attribute - other attributes are useful as well (e.g. how do you initially completely hide a sometimes-necessary AJAX field otherwise - along with its label?)
  • conceptually, I agree that this shouldn't go there as we should let the designers have full control of the presentation. However, in order for the form to function at all, the programmer needs to select a widget, relinquishing designers' control of the design to begin with. In order not to lose the control completely, you end up needing to add "attrs" to the Widget constructor. Let's be consistent and do the same for the label - it's not creating a bigger wart than the one that already exists, and it's IMHO pretty convenient as well.
  • it's certainly no more crufty than admin.helpers.AdminField

Somewhat related to this, BoundField.label_tag currently accepts an attrs parameter but that's not used anywhere in the code. Is it a remnant of some similar idea that never caught on?

comment:3 Changed 13 years ago by Jacob

Triage Stage: UnreviewedDesign decision needed

comment:4 Changed 11 years ago by Luke Plant

Severity: Normal
Type: New feature

comment:5 Changed 10 years ago by Aymeric Augustin

UI/UX: unset

Change UI/UX from NULL to False.

comment:6 Changed 10 years ago by Aymeric Augustin

Easy pickings: unset

Change Easy pickings from NULL to False.

comment:7 Changed 9 years ago by Carl Meyer

Resolution: wontfix
Status: newclosed

This is a convenience, but it doesn't allow you to do anything that you can't already do today by bypassing the default all-in-one form rendering and taking finer-grained control of the rendering. It should be assumed that this is necessary when you have advanced rendering needs.

This change may not be inherently more hackish than what is already present, but it adds one more public API for specifying presentation details via Python code, which is one more bad API we have to support on into the future, even if at some point we're able to move to a system where form presentation is handled in templates instead of Python code.

Note: See TracTickets for help on using tickets.
Back to Top