Opened 7 years ago

Closed 2 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

Description

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 7 years ago.

Download all attachments as: .zip

Change History (8)

Changed 7 years ago by oggy

comment:1 Changed 7 years ago by adrian

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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 7 years ago by oggy

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

http://groups.google.com/group/django-developers/t/ead13c9424b279a2

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 6 years ago by jacob

  • Triage Stage changed from Unreviewed to Design decision needed

comment:4 Changed 4 years ago by lukeplant

  • Severity set to Normal
  • Type set to New feature

comment:5 Changed 3 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:6 Changed 3 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:7 Changed 2 years ago by carljm

  • Resolution set to wontfix
  • Status changed from new to closed

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