Split Input Date and Datalist broken on Android native browser

[davidelrizzo]

I have done a fairly comprehensive UX analysis of how the HTML5 Number Date and Datalist inputs behave for real world inputs across common browsers natively and with a webshim fallback. The only major issues I can see are with Android 4.3 buggy support (tested on a Galaxy S3).

1. The Date input when using the "splitInput": true enables auto tabbing between the three fields. This is buggy and almost unusable on the Android browser. (incidentally this also happens with other common JS input plugins such as jQuery Autotab and the Masked Input Plugin).
2. The Datalist seems to have absolutely no webshim fallback on Android and just displays an input box.

I do not understand why Android is getting polyfilled at all. It does have decent support for Number and Date inputs but webshim replaces them anyway (Chrome Mobile and iOS use the native HTML5 version as expected).
My only solution to this problem is to detect Android browsers with JS and not run webshim for it at all. However this leaves me completely stuck without Datalist support.

• Analysis spreadsheet - Google doc
• Demo page tested - CodePen

[aFarkas]

Wow, nice!!!

I haven't looked into all your research, but will do this. It's great, thank you.

About your Android research regarding that Andorid seems to support input widgets. You are partially right here and what webshims is doing with Andorid is: If Andorid is detected and this browser does not support progress element and fieldset disabled, webshims assumes, that input widgets are not implemented right, even if Modernizr is reporting, that this input is implemented (see also here: Modernizr/Modernizr#769). The reason for this is quite simple: I also made a lot of tests with a lot of Android versions and the result is heavy to got this 100% right. Some versions got it right and some had some problems. Additionally not only the version but also the manufacturer of the smarthpone had influence. The problems were: 1. Datepicker does not offer a clear button/UI, 2. datepicker enters the value in wrong format (some do not add leading zeros, some other use format of OS configuration instead of yyyy-mm-dd), 3. some version do neither trigger blur nor change (Note: I implement missing change event in iOS and others, if at least blur is working) and 4. on older versions not even a datepicker is shown.

This said, while webshims way to handle this is indeed not very "distinctive"/"precise", it is a) fail proof and b) future orientated, if a future version of andorid has those named features (progress element and fieldset[disabled] it will also only use the Modernizr tests. And I think I'm right here, because beginning form Andorid 4.4 the input widgets shouldn't be replaced on Andorid anymore by webshims. With other words: Although webshims could be work more granular with older Android versions, you should not remove it, I had my reasons for this!

About your two concrete issues:
splitInput
This splitInput feature uses scripted focusing, which can't be done on all devices. My question here: Does this feature not exist or does it something strange and bad with the UI/UX. (I can't fix, that it does not work, but I can fix, that there are not other side effects.)

datalist
Will look into this and fix as soon as possible

[davidelrizzo]

Thanks for the quick response, I think you are definitely right about the Android browser just behaving terribly in this case.

• I am not too concerned with the splitInput, the Android browser simply cannot cope with any kind of auto tabbing. I can just use the native input or even use the webshim 3 dropdown date version if necessary. You may just want to make a note about it's bugginess for Android in the docs.
• The datalist is my main concern because neither the native or webshim version works on Android. I will have to stick with jQuery UI Autocomplete for this until either webshim works here or Android browsers support the datalist.

As a side question, you may have noticed I also tested a type of input I call a Numeric Code. Such as a number only postcode, PIN or Credit Card number. For this type of input it makes sense to use text fields on desktops where the maxlength and pattern validation come into play and number fields on touch devices where you get the numeric keypad. The number field implementation of webshim is not helpful here because none of the features like grouping or stepper are needed and the maxlength is not carried through.

• Actual question: Is there a way to disable webshim polyfill on a specific input? I know you can choose to only implement certain types of form-ext, but the only way I could turn it off for one specific input it in this case was to use input type:text and change to type:number with JS after webshim has already run.

[aFarkas]

As already said datalist will be fixed soon. Additionally native datalist is comming for Android. ;-).

About postcode, pincode and credit card number, those kind of inputs are "numeric" or "digits", but not type="number". The right markup for this would be:

<input type="text" inputmode="numeric" pattern="[0-9]*" maxlength="" minlength="" />

This should work with iOS and Firefox for Android. Chrome is working to get this feature soon into Chrome for Android. You should not turn it into type="number", because some browsers will remove leading zeros and other stupid things.

As a workaround you could detect, wether inputmode is supported and if not replace it with type "tel", it's also semantically wrong, but won't have so much side effects.

This said I will also add a new class called ws-noreplace with next release.

[aFarkas]

Ok, I wanted to look into your datalist issue and tryed the following demo page with Anrdoid 4.3. And it worked pretty good. So I can't reproduce your issue. Can you test or help with some more information?

[aFarkas]

@davidelrizzo
I would like to make a new release, because the following fixed bug really needs a new stable.

But before releasing, I also want to look into your datalist issue. As you see above, I can't really reproduce it. Can you help here? Additionally, from your spreadsheets I see, that you mention type number validation does not work in IE8. For me this is working. Can you help me here, too???

[davidelrizzo]

Oh, you are right the datalist on your configuration page does work on my 4.3 Android browser. I will have to do some more testing when I am back at work on Monday, but most likely my sample page was not correct somehow.

As for the IE8 validation, the reason I did not bring it up is that I had a feeling it was a local issue. I had someone else test it on like 2 levels of citrix login so I have a strong suspicion something wasn't right there. I will check this again too and let you know.

I am keen to keep that UX analysis spreadsheet up to date and will likely add the time and month input too.

Thanks once again for all your help and work. Webshim is seriously one of the best tools for anyone building online forms period.

[aFarkas]

Ok, this was enough information for me :-D. Just fixed it.

[davidelrizzo]

@aFarkas I had a careful look into the issues we discussed.

1. The datalist does indeed work on Android 4.3, not sure exactly what I was doing wrong, adding customDatalist: true seemed to help. My solution therefore is to polyfill 'forms' on Android browsers and 'forms' and 'forms-ext' on all other browsers, I still don't want webshims overriding the Android inputs 4.3+ supports. Android behavior for these inputs is inconsistent though, thankfully in my case I do not have to support older versions/devices.
2. Also after double checking the validation on IE8 it is working. I was also missing addValidators: true.

I also had a look into the inputmode="numeric property you suggested for the Numeric Code inputs. Currently none of the browsers support it (not even iOS), I am happy with my implementation because it solves all the UI issues and none of the browsers I tested prohibited leading zeroes. Your inclusion of the ws-noreplace class will make this even easier.

So that concludes this round of my analysis. Websims is (one way or another) solving all my problems and I will begin to implement it into our projects. Thanks again.

[aFarkas]

@davidelrizzo

I just added some small inputmode="numeric" support for mobile browsers: http://jsfiddle.net/trixta/7NEBb/. Note: This only works with the newst "unstable" version of webshim!

[davidelrizzo]

@aFarkas polyfilling inputmode is a great idea. I have a few observations:

Keypads vary wildly!

• The Google and Samsung 'tel' keyboard allows all sorts of special characters plus spaces. The iOS 'tel' keypad does not allow spaces.
• The iOS 'number' keypad is just the number part of the regular keypad (you can still change to the alpha keys). The Google 'number' keypad allows numerals, hyphens, spaces and the minus sign only. The Samsung 'number' keypad allows ONLY numerals (which is totally broken because you can't even enter decimals).
• The number keypad invoked by setting pattern="[0-9]*" on iOS is different to both the iOS 'number' and 'tel' keypad. It allows ONLY numerals. this type of keypad is a quirk of iOS, there is nothing in the spec that says this should happen.
• The above variations are only for the 3 keyboards I checked, you can install hundreds of other 3rd party keyboards on Android and I hear Apple are about to release customized keyboards too!

So this raises some difficult questions around

1. What is the semantically correct markup for a Numeric Code input and
2. What is the implementation on current devices which gives the best User Experience?

I dont think we can make absolute assumptions about the exact nature of a Numeric Code. A PIN number should only have numeric values, a Credit Card might be nicer to separate groups with spaces and hyphens, a Serial number may have brackets or who knows what else. As inputs it is definitely best practice to allow users to enter values in the way they feel comfortable. Given the input is type="text" on desktops, the value always needs to go through Server Side cleanup and validation anyway.

My Proposal
Let the developer decide how they want inputmode to be polyfilled.

• First priority, if type="text" and pattern="[0-9]*" on iOS, implement the special iOS numeric only keypad.
• If type="text" and the device has custom keypads (ie. modernizer detects 'touch') change the input type to match the inputmode specified. (eg. inputmode="numeric" changes type to number, inputmode="tel" changes type to tel etc..). This way the developer can decide if their input more closely matches a 'number' or 'tel', perhaps the other types of input modes may need polyfilling in the future too.
• You will have to keep an eye out for any native support of inputmode once browsers/devices do start supporting it you will have to drop the pollyfill. I hope for everyone's sake that when they do, there is a way to detect it!

[aFarkas]

Hi,

I made same observation, but my conclusion is a little bit different here. To sumarize it:

inputmode="numeric" should give us the following charckters: +-.,0123456789
type="tel" depends on the device, but there are devices, which will give you only: +0123456789

Which means a switch between inputmode="numeric" to type="tel" is obtrusive.
A switch from inputmode="numeric" to type="number" might give you the right keyboard, but there is always the possibility of value sanitatzation, which will change/remove values like: +01231 to 1231 or an empty string. Means that this is also obtrusiv.
There is actually no usecase for inputmode="tel" on an input. It's more for a textarea and for the completeness of the spec.

My current approach is therefore to always look for both: pattern="[0-9]+" and inputmode="numeric" (The first pattern already works on iOS...). Maybe I will improve this to detect things like [0-9]{3,9} and so on and do the fix also on iOS.

You are right, that sometimes an inputmode="numeric" to type="number" would be better or sometimes also an inputmode="numeric" to type="tel" without an explicit pattern is appreciated by a developer, but those kind of switches are obtrusive and need to be guarded by an option or a specific class/attribute on the element. -> The developer has to explictly opt-in for this + I have to document it somewhere/somehow.

Any suggestions? Maybe:

<input inputmode="numeric" data-wsmode="tel" />
<input inputmode="numeric" data-wsmode="number" />

About native support. There is a way to detect it and I'm using this detection already. Interestingly inputMode is already supported on Chrome Desktop. Don't understand why :-D. And on Firefox it is hidden behind a flag: "dom.forms.inputmode" + something different/similiar "dom.mozInputMethod.enabled"

[davidelrizzo]

Seems messy to me, if you want to add another attribute like data-wsmode to change input type on devices then why bother tying that with inputmode or pattern at all?

Looking at the spec for inputmode it says that the intent of this property is to specify what type of input mechinism would be most usefull, ie. which keypad to use without effecting the type or sanitization properties. However as we know that is not possible on any any current device. Polyfilling from inputmode directly to type I would think is a clean and neat way to solve the problem as the inputmodes in the spec map 1 to 1 to the different types and keyboards. This puts control entirely in the developer's hands without any need for custom attributes and if they don't want to use the polyfill (and any sanitation that implies) they simply omit inputmode. Once inputmode is properly supported on that device you simply drop the polyfill.

The only odd behavior then is the iOS pattern numeric keypad, which is Apple's attempt to implement inputmode before it was in the spec. Given the only way to enable this keyboard is with pattern="[0-9]*", you should probably not polyfill inputmode on iOS when that pattern is present.

[aFarkas]

Ok, you are right about this being messy, but I will never ever do a switch to [type="number"] without an explixit opt-in by a developer.

My current work on this, can be seen here: http://fiddle.jshell.net/trixta/7NEBb/show/

The first example simply shows, why I won't use the type="number" it's simply to obrtusive. All other examples show how inputmode="numeric" is polyfilled. In summary: On Android and iPad inputmode is always polyfilled and on iPhone, the developer has to add a pattern. While iOS only detects [0-9]* and \d*, webshim will detect more (but not all suiteable) patterns.

I think this is the best way to do this automatic. As already said, in some situations, there might be a better different approach, but those approaches are obtrusive and needs to be hidden behind a configuration. If you want such a configuration please open a new ticket.

[davidelrizzo]

Fair enough. I think you solution is practical while being as safe from assumptions about the intended input as possible. This seems to fit with your Webshim philosophy of polyfilling without harm.
Given this is now released on the latest stable library and fulfills all my requirements for Numeric Code inputs I will probably end up implementing it as you have. - great work

[aFarkas]

Wow, thanks. Kind words.