Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
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
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
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
@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
@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
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
Issue already fixed, albeit in a different form to the one proposed.
Original comment by stefdawson
on 23 Aug 2013 at 3:36
Original issue reported on code.google.com by
ph.witte...@gmail.com
on 22 Aug 2013 at 1:14