Specify autocapitalize

[travisleithead]

Filing as an issue because this is implemented in WebKit, so has some degree of interop already.

This issue was transferred from the Bugzilla bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=12409 (which has links to other related bugs/conversations about this issue).

See Mounir's proposal here: https://github.com/mounirlamouri/html-autocapitalize/blob/master/proposal.md

We should figure this out for v.5.1.

[chaals]

This looks like it is still waiting for more implementation, although that seems likely to happen.

So the question is whether it should be HTML 5.1 or later. Leaving it without a milestone for now.

[travisleithead]

See also Issue #269

[chaals]

Where is this up to in implementation?

[cvrebert]

Implemented in Chrome: https://www.chromestatus.com/feature/4529989986811904

[edent]

Tested autocapitalize on Android today. Works in:

• Opera (Blink)
• Opera Mini (?)
• Dolphin browser (Webkit)
• Samsung Browser (Blink)
• Microsoft Edge (updated: Blink)
• WeChat (?)

Doesn't work in Firefox (regular or nightly). Nor in UC Browser.

Is that interoperable enough to add into the spec?

[stevefaulkner]

Yes

…

On Tuesday, 7 November 2017, Terence Eden ***@***.***> wrote: Tested autocapitalize on Android today. Works in: - Opera (Blink) - Opera Mini (?) - Dolphin browser (Webkit) - Samsung Browser (Blink) - Microsoft Edge (EdgeHTML) Doesn't work in Firefox (regular or nightly). Is that interoperable enough to add into the spec? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#208 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAzBEwPsBcYfKA6yhNyv5Q3aPj3vKnarks5s0QHHgaJpZM4IIuiY> .

-- -- Regards SteveF Current Standards Work @w3c <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>

[travisleithead]

Actually, Microsoft Edge on Android uses Blink 😉 https://mspoweruser.com/microsoft-edge-uses-webkit-engine-ios-blink-engine-android/

[chaals]

@edent :

Tested autocapitalize on Android today

Did you test in cyrillic/greek? What other scripts have capitalization?

[LJWatson]

@chaals "Did you test in cyrillic/greek? What other scripts have capitalization?"

Wouldn't that be a platform implementation matter, rather than a spec matter?

[asmusf]

Don't really understand the use case. For using virtual keyboards, I can think of more "assistive" autocapitalization behaviors than those given here, but they would then benefit from being language-aware (e.g. "I" in English). Then there are scripts like Georgian and Cherokee where there are parallel forms that are close to, or actual case variants, but with important differences, some of them due to the history of developing / using / encoding the script.

[edent]

@asmusf while I can't speak for the originator of the spec, it's useful in fields like "postcode" to have all the characters capitalised. Same for car registration plate. "Full Name" would also generally use the words style capitalisation.

Three points

1. This is only a hint. If your name is Vincent van Gogh, you should be able to change the capitalisation.
2. This doesn't replace server side validation - but in that way it is no different from type="email" or type="tel".
3. Whether it is useful isn't the question. It is already being used by several browsers.

[chaals]

Originally noted by @agcolom in #1072, raising here.

I think there should be a "none" value listed, that it should represent the default state if either the attribute is not present, or the value is not recognised by the user agent.

[chaals]

Changing milestone, this seems unlikely to get in on time because it's tricky, and I don't have a good testing setup :(

[chaals]

See also Apple's documentation - they made up the feature as far as I can see.

[chaals]

Apple defaults to "sentences" for inputs in the text state. But for better compat, it seems reasonable to default to none.

For passwords it is usually critical to do so. (Not always. I have several real-world passwords where the system forces uppercasing and applies a mechanism equivalent to autocapitalize="characters")

[aphillips]

@chaals Having a system apply uppercasing is different from having the user-agent do it. Among other things, there are annoying corner cases in case folding.

sentences autocapitalization is pretty common in mobile keyboards. It's usually the default state and is activated by typing period-space.

words could prove troublesome for some users (@edent "this is only a hint" means a lot of backspace-fix for the end user in corner cases. it's not really a "hint" if implementations implement it properly).

none is usually wanted for unformatted text, like passwords. Recall that there is a difference between post-input processing and the end user typing prose.

[chaals]

@aphillips re sentences as a default in mobile: yep. I assume that is related to the implementations which have it as a default for certain states of input and for textarea. I'm also wary of issues like matching conventions for capitalising words within sentences - language adjectives in English, nouns in German, ...).

As noted already in linked docs, none is important for stuff like passwords and URLs. I'm not sure what the use case is for words. I can see it in some languages/scripts for fields like name, which is how my own phones sometimes behave.

Thanks for the link to charmod, that should go into the text we add, along with pointers to Unicode and a potted but hopefully helpful and not harmful summary of the key points.

One reason for pushing this off the near milestone is that it is complicated. I would be grateful if i18n took this on as a tracking issue, but will wait for you to re-tag it (or tell me to do so). And it seems to behave differently for typed characters and pasted text. And we still need tests and results to understand what really happens (and whether the 'needs implementations' label should go back - I am personally reluctant to put this in except as "at risk" if it doesn't work across scripts and languages.

[chaals]

I wrote

For passwords it is usually critical to do so. (Not always. I have several real-world passwords where the system forces uppercasing and applies a mechanism equivalent to autocapitalize="characters")

At the moment these seem to be done within the application. One goal is that if passwords require uppercase, a field can reliably use this attribute. But we are not close to that now :(

[chaals]

Should autocapitalize apply to the date state (and if so does anyone implement it)? I have it (provisionally) not applying in #1072 and wondering if anyone would be upset by that.

[r12a]

Did you test in cyrillic/greek? What other scripts have capitalization?

See http://rishida.net/blog/201512.html#20161106

Note that Cherokee may require autocapitalize="characters" to be the default for the time being, because of current font support, but that may change over time.

The Georgian default should presumably be autocapitalize="none", but i'm not sure whether Georgian keyboards on mobile devices currently offer case alternatives. It's presumably occasionally useful that they do, though rare.

Btw, i wonder whether anyone reading this knows whether Germans punctiliously apply the normal noun-capitalisation rules when typing on mobile devices?

[asmusf]

@r12a To your last question: Some don't and others object to that, forcefully. Many report such texts "hard/impossible to read". You can find that kind of meta-conversation preserved in forum discussions; my conclusion would be that going all lowercase is not seen as generally acceptable, even if it's known that input was done on a mobile device.

[aphillips]

@r12a @asmusf I'd argue that it's irrelevant. autocapitalize isn't about language specific things such as what the autocorrect in the keyboard does. It's about influencing the input mechanism to provide application specific capitalization. For free text, this is normally sentence support. For a few fields that want to be SHOUTED, it's characters. I suppose occasionally the hint will be none (to disable sentence or whatever the default is). But it really shouldn't be language/input method specific IMO. That's up to the specific keyboard or input method--or to the user.

[r12a]

@aphillips i'm not so worried about German here, because i'm guessing that a word value for autocapitalize wouldn't be appropriate as the default.

However, i don't want to lose sight of the idea that normal support that is sentence-based may be unhelpful (and this whole thing is about being helpful) for Cherokee and Georgian, for which more helpful default settings appear likely to be character and none, respectively. I guess the question is whether it's down to content authors to set the defaults in those cases, or whether applications should be expected to change the default settings based on the current language.

[chaals]

We added this to the spec. Please raise specific issues against the text that is there now... (or will be when we fix the build script that seems to be playing up).