The current number field was modified from a number type input to a text almost 12 months ago. Here are notes from the maintainer at that time:

While coding standard do not normally allow commenting out code, I have elected to simply comment out the setting of the elements type to 'number', in the hopes that HTML5 browser support will improve to address the decimal issue. I also left the step, min, and max in the HTML so that a theme or module could implement in-page validation.

Commited to 7.x-4.x and (reluctantly) 8.x. By the time 8.x is out, this issue may have improved.

The decimal issue was documenated as:

The odd thing is that in Chrome, it sets the decimal placeholder based on the browser language/locale, not from the Website. So even if we said the placeholder was a period, Chrome would require it be a comma anyway.

Bringing this back up for review since some time has passed. See https://www.drupal.org/node/2290029

CommentFileSizeAuthor
#5 webform-number-html5-2543632-05.patch2.11 KBrobertwb
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

lance.gliser’s picture

Issue summary: View changes
DanChadwick’s picture

DanChadwick’s picture

Status: Active » Postponed (maintainer needs more info)
Related issues: +#2202905: Decimal numbers with comma as placeholder fail validation in Chrome

Do you have any evidence of browser compliance, and the population of the installed base of non-compliant browsers? Absent such information, it would appear that HTML5 number elements still aren't ready for prime time.

DanChadwick’s picture

Version: 7.x-4.x-dev » 8.x-4.x-dev
Status: Postponed (maintainer needs more info) » Postponed

Moving to the D8 branch for future consideration.

robertwb’s picture

I would like to propose an intermediate solution, carried out by the attached patch.

Problem/Motivation

Mobile user experience is significantly increased as a result of HTML5 number fields. Numerically intensive apps are especially affected by this.

Proposed resolution

Add a boolean switch at the form:component level for each numeric component config "Use HTML Number Field". Default to 0 so that no existing forms are affected.

Remaining tasks

Review

User interface changes

Added checkbox "Use HTML Number Field" to config screen for Webform Number components.

API changes

None.

Data model changes

Adds configuration key:value pair html5:0/1 in column "extra"of table "webform_component" when component configuration forms are saved.

robertwb’s picture

Status: Postponed » Needs review
DanChadwick’s picture

Status: Needs review » Postponed

Re #5, thanks for the patch, but my concerns about browser compatibility in the related issues remains. We tried html5 and had poor results. I suspect that there is still a large installed based of incompatible browsers. I *still* don't know what the correct behavior is for decimal points that aren't periods.

Also, the patch will never be tested by the testbot because the version of this issue isn't 7.x-4.x.

Absent a groundswell of demand, I think the best solution would be to override theme_webform_number in a custom theme and generate the html5 there. This way we don't introduce a setting in webform core that we know will have bugs with international numbers.

Changing back to postponed because I think the D8 version should consider using html5, or perhaps having an option for it. Who knows when that will be....

robertwb’s picture

@DanChadwick - sorry about the version confusion.

Per the HTML5 compatibility issue, I think this patch provides an appropriate workaround for the following reasons:

  1. It is up to the form developer to opt for HTML5
  2. HTML5 number field is disabled by default

Thus, nothing breaks - and it is then up to the community of form developers to inform as to the real world compatibility with HTML5 on the wide range of browsers. Otherwise, how are we to move from "suspecting there are..." to "knowing what the status is"?

DanChadwick’s picture

On other similar issues, we have moved slowly. I understand the point that the browser bugs -- which were and will be again reported as webform bugs -- are not triggered by default. But it has been the webform project's policy that if we put in support for a feature, that it works, even if it isn't our fault that it doesn't work.

If there weren't a straightforward workaround, I could see making an exception in this case. But adding the theme function is trivial.

robertwb’s picture

I get it -- and it makes sense with a project this large. Really, this patch is for me much easier than theming and so at least its now out there for me and others to put browsers to the test because, while the theme workaround is trivial for coders, it is not necessarily trivial for designers and so stands in the way if testing.

I don't want to take up your entire day here, but I am wondering if the issue has multiple facets that may have multiple solutions. The facets:

  1. Showing the numeric "keyboard" in mobile screen
  2. Showing numeric format stylees like thousands and decimal points

Can we separate these two in implementation? To me, the first one is the largest usability impact and if it can be enabled without involving the 2nd there should be a clear path.

DanChadwick’s picture

Showing numeric format stylees like thousands and decimal points

The issue isn't "showing" them, but rather that if they aren't the US standard, html5 number elements are broken on various browsers/platforms. I'd have to re-read the related issues to refresh my memory on the exact circumstances. Webform cannot adapt to the broken browsers or we would have done that, rather than back out html5 numbers, which were previously in 7.x-4.x.

robertwb’s picture

@DanChadwick - thanks again for the follow-up, I should restate *showing* stylees as *supporting* stylees. I think that you pose 2 good questions in your response to the OP here which we haven't managed to answer : What is the population of noncompliant browsers, What evidence of better HTML5 Number support. However, I think that to consider this issue thoroughly reviewed, we need to have an accurate summary of just what those issues ARE before answers can be attempted. I will elaborate on both of your questions below, and would recommend that the issue status be set to "Postponed (maintainer needs more info)" to reflect the fact that the issue is not well quantified.

What is the Population of installed Non-compliant browsers

http://caniuse.com/#feat=input-number - non-supported at all is only Opera mini, but this estimates population at 5% (see next resource, however for more Opera)
https://html5test.com/compare/browser/index.html - does not describe "Opera Mini", but ther earliest version of "Opera Mobile" - - is listed as fully supporting 11.5

What evidence of better HTML5 Number support?

I think that firstly, a good summary of the issues is in order. Also, it would be good if we could specify exactly what criteria type=number support should be re-enabled. Below are the beginnings of a list of issues gleaned from the queue and also some possible workarounds.

  • Negative numbers not supported on iPhone - https://www.drupal.org/node/2290029#comment-9017985 - My experience shows this to be fixed (see image 1)
  • "Thousands separator creates invalid value" - one instance lists Chrome as mangling an entry of "10,50" (german) to "10.5" - commas are not allowed at all in the current Chrome Version 45.0.2454.85 m -- not sure when this went into effect -- but it would seem that this is no longer a possibility if Chrome will not allow commas in # fields.
  • (workaround) "Thousands separator creates invalid value" - AS this issue seems to be about the failure of webform_number_format_match -- there IS a workaround suggested in one of the original threads - set thousands separator to none (https://www.drupal.org/node/2290029#comment-8901139). No one in the thread actually responds to the suggested workaround, so maybe it doesn't work, but should be tested. Or maybe it's considered to be a sub-standard level of operability for form designers.
  • (workaround) Create a New HTML5 Number field -- this might be a reasonable solution, allowing form designers to go into this with eyes wide open. Support for different formatting and validation widgets might then be added as they are.

Image 1: iPhone negative number support Safari.

Only local images are allowed.

DanChadwick’s picture

I believe the thousands and decimal issues are related because some browsers return the characters in the local standard and some as US standard. But then, I haven't installed all the browsers, all the versions, and tested them with these settings on localized systems. Can you find any references to testing on this? And too the installed base.

The current status of this issue, D8/postposed, reflects that this issue won't be addressed until the core functionality of webform has been successfully ported to D8. Absent new information, of course.

I still think it is too early to use html5 number elements unless there is evidence to the contrary.

robertwb’s picture

Working on this:

Can you find any references to testing on this?

And to this:
And too the installed base.

I think that the "Can I Use" link is a step, but I don't know it's sourcing so hard to say how robust it's percentage estimates: http://caniuse.com/#feat=input-number

Do you have guidelines on creation of a D7 issue for this?

DanChadwick’s picture

The caniuse information isn't very helpful. I don't really are if the browser doesn't support the attribute and displays a text field instead. I care that it screws up the decimal and thousand separator. Finding that data sounds challenging...

caniuse does have installed base numbers though.

robertwb’s picture

> caniuse does have installed base numbers though.

Yeah, that's about all that matters there. Not sure if you caught that the most recent version of chrome don't permit a comma to be entered.

And to a D7 issue - any guidelines?

DanChadwick’s picture

This issue is the right place to discuss this. If it gets implemented for D7, will be ported to D8 in this issue. If not, then it stays a d8 issue.

robertwb’s picture

Sounds good. Thanks for the counsel.

fenstrat’s picture

Status: Postponed » Closed (outdated)

Closing to clear out the old Webform 8.x-4.x branch. See #2827845: [roadmap] YAML Form 8.x-1.x to Webform 8.x-5.x.