4👍
Why does that enhance usability? The only difference is that you’ve added a class
, and for some reason removed the id
attribute, therefore making it impossible to use a label
. I can’t see any circumstances under which making something less accessible would make the UX better. And removing the dynamic ability of Django forms to re-display the wrong values in case of validation failure similarly seems hardly a step forward.
I can’t really understand what your question is asking, though. If you really want to use this less-usable markup in your template, why not just do it? You have to provide the template for the contrib.auth views in any case, so there’s your opportunity.
Of course a much better way is to simply subclass the LoginForm and add your HTML class there:
class LoginForm(auth.forms.AuthenticationForm):
username = forms.CharField(label=_("Username"), max_length=30,
widget=forms.TextInput(attrs={'class': 'loginput'}))
and pass this form in the extra context to the login url:
(r'^accounts/login/$', 'django.contrib.auth.views.login',
{'template_name': 'myapp/login.html', 'authentication_form': LoginForm}),