Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#9478 closed (wontfix)

Default id attribute for form field 'id-field' should be avoided

Reported by: daveyjoe Owned by: nobody
Component: Forms Version: 1.0
Severity: Keywords: forms html css
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

When django returns a HTML form element generated by the form class it typically looks like:

<label for="id_email">Email:</label> <input id="id_email" type="text" name="email" maxlength="75" />

An id with an underscore in it should be avoided for compatibility and historical reasons, as detailed in the following article: https://developer.mozilla.org/en/Underscores_in_class_and_ID_Names

I suggest the following as a typical output instead:

<label for="id-email">Email:</label> <input id="id-email" type="text" name="email" maxlength="75" />

This change would be backwards incompatible. I reccommend implementing it as a hidden option until 2.0 and then use 'id-field' as the default option.

Change History (5)

comment:1 Changed 7 years ago by brosner

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to wontfix
  • Status changed from new to closed

You can already control the default auto id that Django gives in that attribute. Using the auto_id keyword argument on the Form allows you to control how it is created. The current default is id_%s. That article is a little over seven years old and for those that actually need to do this they can override that keyword argument.

comment:2 Changed 7 years ago by daveyjoe

  • Resolution wontfix deleted
  • Status changed from closed to reopened

I understand that it is perfectly possible to change the attribute using the auto_id keyword but surely django's default should not be something which is actually not permitted under the CSS1 and CSS2 specifications.

I'm not suggesting that the change be made right away, I'm simply suggesting that this should be fixed for the next release which will introduce backwards incompatible changes (2.0 as far as I know).

I'm going to reopen this ticket just once because I think it needs to be reassessed.

comment:3 Changed 7 years ago by brosner

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

Please do not reopen this ticket. If it is wontfix'ed please take the discussion to django-developers. Then if there is a consensus that maybe I overlooked something then it can be reopened citing the discussion. I am still standing in what I said. While I see that it is not permitted, it does work. If it didn't work then I am sure that in the year's existence of newforms that this would have been addressed before. I can see reasoning for using an underscore over an hypen due to possible issues in Javascript.

If you have a stronger argument I would appreciate hearing it, on django-developers of course. :)

Oh, I also just noticed #8440. It has been addressed in CSS 2.1.

comment:4 Changed 7 years ago by daveyjoe

Ok, thanks for the detailed reply.

comment:5 Changed 7 years ago by anonymous

  • milestone post-1.0 deleted

Milestone post-1.0 deleted

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