== Modernizing (a bit) some of our HTML form elements
We have [[a Django web app ../python/DjangoORMDesignPuzzleII]] for
handling requests for Unix accounts, which has some HTML forms (in
fact it's basically half HTML form filling). These forms (and all
of the app's HTML) were put together years ago and only looked at
on the desktop at the time. Recently, I poked around the app's forms
on the work iPad to see how it would go. Even after I fixed [[the
traditional viewport issue WTResponsiveDesign]] (see the comments),
there were little irritations; for example, when you entered your
desired Unix login, the iPad wanted to capitalize the first letter
as part of its general auto-capitalization. Our Unix logins have
to be all lower case, so this was a point of friction. Naturally
I wondered if it was possible to improve the experience.
(Our Django web app was written in 2011, and we first got [[a work
iPad in mid-2014 ResponsiveDesignNeed]]. In 2011, not checking phone
and table browser behavior was not crazy; today, it probably is and
we likely should pay more attention to how all of our sites look
on them.)
Unsurprisingly, there are ways to improve the situation by simple
changes to our HTML, although not all of them were completely
successful. You can find a variety of people writing about this
online, and also [[the MDN page on __ form fields
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/text]],
although it doesn't mention [[the _autocapitalize_ attribute
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/autocapitalize]].
The short version is that we apparently want to set all of the
following attributes for text field that is supposed to be a login:
.pn prewrap on
> autocorrect="off" spellcheck="false" ...>
Spellchecking is obviously not applicable; very few logins are
dictionary words. Autocorrection is similarly probably not desirable,
and autocapitalization is what we started out not wanting. The
_autocorrect_ attribute is a Safari extension, but apparently
Android may want you to use [[_autocomplete_
https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete]]
instead (which is a nominally standard attribute with all sorts
of possible values).
The form also has a field for people's names. I set this to
'_autocapitalize="words"_', and should probably also set it
'_autocomplete="name"_' now that I've read about it. On my iOS
devices, some combination of the attributes we're using (possibly
including a '_name="name"_' attribute from Django) causes Safari
to be willing to autocomplete it from your contacts, which is handy
if your contacts include yourself.
My less successful experiment was setting a [['_pattern=..._'
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/text#pattern]]
and a '_title=..._' attribute on the field for your login. What I
wanted was for the browser to automatically react with a helpful
error message when you entered an invalid character, but my flailing
around so far hasn't produced this. We have [[some additional client
side validation WhatToValidateClientside]], but they involve a
server check and so only trigger when the field is de-focused;
faster feedback would be nice. However, my initial reading left me
with the impression that doing a good job of this across both desktop
and mobile browsers would require more JavaScript than I wanted to
write.
([[MDN has a useful page on general form validation
https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms/Form_validation]],
which I haven't read all of.)
All of this (including writing this entry) has done a good job of
showing me how ignorant I am about modern HTML. Things have definitely
changed here over the last decade or so, which is good to see even
if it leaves me well behind the times.
PS: Django is already setting appropriate '_type=..._' values on things
like the field for your email address, or that would be another obvious
and necessary change to make here.