user name field / login pane - prevent autocapitalization on iOS

[GoogleCodeExporter]

Safari on iOS has that annoying habit of automatically capitalising usernames 
on the login pane. This can be prevented with the autocapitalize attribute:

<input type="text" name="p_userid" size="32" id="login_name" value="" 
autocapitalize="none">

This has no known detrimental side effects on other platforms where the 
attribute is currently ignored.

Reference
https://developer.apple.com/library/safari/documentation/AppleApplications/Refer
ence/SafariWebContent/DesigningForms/DesigningForms.html#//apple_ref/doc/uid/TP4
0006512-SW2

https://developer.apple.com/library/safari/documentation/AppleApplications/Refer
ence/SafariHTMLRef/Articles/Attributes.html#//apple_ref/html/attribute/autocapit
alize

Original issue reported on code.google.com by ph.witte...@gmail.com on 22 Aug 2013 at 1:14

[GoogleCodeExporter]

Thanks for highlighting this. A few extra things to consider before making a 
decision either way for core:

1) Is turning autocapitalize off broadly applicable to any other fields (e.g. 
form name, page name, sheet name, add user login name, ...?) or is the admin 
side login name the only place it's useful?

2) What about autocorrect? Presumably that should be turned off in 
login/username fields too so it doesn't try to correct dawsons to damsons, or 
whatever.

3) The first link you referenced states "Safari on iOS turns the autocorrect 
and autocapitalize attributes off in login fields and on in normal text 
fields." Does that imply there's some way to 'tag' fields, perhaps by a known 
class or something, so iOS automatically applies the correct autocapitalize and 
autocorrect behaviour, without having to explicitly set it as an attribute? 
Can't find any Apple docs on it if so, and nothing in the W3C spec that I can 
see indicates type="login" or equivalent.

If there's a way to tag or label the fields so browsers behave according to the 
field's perceived function, I'd prefer to do that than liberally sprinkle Apple 
extension attributes throughout the code.

Either way, anyone please feel free to chime in with all places where this 
automatic behaviour is likely to be counter-productive.

Original comment by stefdawson on 23 Aug 2013 at 9:31

• Added labels: Type-Enhancement

[GoogleCodeExporter]

If the attributes are vendor specific, and not valid HTML5, then I'd rather not 
see them in our code.

Original comment by flaming....@mac.com on 23 Aug 2013 at 12:06

[GoogleCodeExporter]

My thoughts entirely. I can't _see_ them in the HTML spec, and the Apple docs 
list them as an "Apple extension" so I assume this is an iOS thing only. But I 
don't mind giving them a nod as to the field's usage and letting the browser 
figure out what logic to apply.

Original comment by stefdawson on 23 Aug 2013 at 12:18

[GoogleCodeExporter]

Yes, the suggested attribute is non-standard and vendor specific (currently), I 
though that was clear fro the get go.

1/ Given that, I would only apply it to the login pane as a convenience to the 
user.

* it is the one place that a iOS user will visit always and will want to go 
through as soon as possible, and with a minimum of fuss - OK, I know… the 
‘remember me’ check-box; which is something I never use, nor does one of my 
clients who is a heavy iOS user; besides, that only really works if you always 
use the same platform / browser.

If other users are like me, the login page load, I (blindly) start typing name, 
press next, type password, press submit - followed by $swear_word as the login 
failed.

(on the other hand, iOS7 may alleviate the problem with its support for 
keychain autocomplete, although I had some issues with it on my iPad - it is 
still beta software though)

2/ the attribute(s) _could_ be useful in other places, such as form names, add 
user-name, perhaps custom fields; however the user is in less of a hurry in 
those cases and may pay more attention.

(different would be if we developed an iOS specific (web-)app…)

3/ iOS turns off auto-correct and auto-capitalise for input type=url and input 
type=email by default,  and of course on input type=password. There is no input 
type=login unfortunately. So no, for input type=text, there is no other way to 
have it work than adding the attribute to the appropriate control.

Original comment by ph.witte...@gmail.com on 23 Aug 2013 at 1:03

[GoogleCodeExporter]

Wait, hang on a mo. I understand this from an aesthetics viewpoint, but are you 
saying that the login box is actually case sensitive? It's not in my 4.5.4, nor 
on 4.6-dev and I have accounts defined with both an upper- and lower-case first 
char. I wonder if this is language-specific behaviour?

If it is case sensitive for you then we need to figure out what's going on. 
From memory, Txp is supposed to compare the login names in a case-insensitive 
manner and then set your user name (inside Txp) to match the one as set when 
the account was defined. The password is the only part that is case sensitive, 
since 4.4(ish?)

Original comment by stefdawson on 23 Aug 2013 at 1:29

[GoogleCodeExporter]

The current Textpattern way of adding attributes to the arrays make's it 
difficult to then remove these attributes again in the future, so my vote is to 
keep them out of the code for now, even if they do have UX benefits. If they 
ever become part of the spec we'll add them in, of course (and if we find a 
better way of adding attributes to HTML tags).

Original comment by flaming....@mac.com on 23 Aug 2013 at 1:31

[GoogleCodeExporter]

re comment 5

On two different sites/ w. different hosts the login pane bounces me around 
when Mobile Safari uppercases my login name. Both sites are quite old (one from 
the origins of TXP time, one is 5y+).

Original comment by ph.witte...@gmail.com on 23 Aug 2013 at 1:38

[GoogleCodeExporter]

@stefdawson We don't have to figure out anything. The casing is dictated by the 
database and its database/table/field charset (inherited by defaults on 
create). If you configure your name column to use utf8_*_ci it's 
case-insensitive. If you set it to utf8_* (without _ci suffix ) it's not. If 
you use localized set (e.g. utf8_swedish_ci), MySQL will also handle 
transformations (ä <-> a, ae <-> ä).

I have this strange feeling that I've explained this before.

Original comment by jukka.m.svahn on 23 Aug 2013 at 1:47

[GoogleCodeExporter]

@ph.wittenbergh: ah, the age of your installation explains it. Ruud applied a 
fix for that some time ago (r2856!) and then Gocom went even further recently 
in r4902 with the login cookie.

In more recent builds, logins should be case-insensitive, save for the 
situations that Jukka outlined above. In which case, this is a non-issue, 
agreed?

Original comment by stefdawson on 23 Aug 2013 at 1:54

[GoogleCodeExporter]

Ok, if that is the case, the issue is much less pressing, esp if it is actually 
difficult to add the attribute in the present code base.
I can continue using js to add the attribute on my side.

Original comment by ph.witte...@gmail.com on 23 Aug 2013 at 2:00

[GoogleCodeExporter]

Issue already fixed, albeit in a different form to the one proposed.

Original comment by stefdawson on 23 Aug 2013 at 3:36

• Changed state: WontFix