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
Comment | File | Size | Author |
---|---|---|---|
#5 | webform-number-html5-2543632-05.patch | 2.11 KB | robertwb |
Comments
Comment #1
lance.gliser CreditAttribution: lance.gliser as a volunteer commentedComment #2
DanChadwick CreditAttribution: DanChadwick commentedComment #3
DanChadwick CreditAttribution: DanChadwick commentedDo 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.
Comment #4
DanChadwick CreditAttribution: DanChadwick commentedMoving to the D8 branch for future consideration.
Comment #5
robertwb CreditAttribution: robertwb commentedI 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.
Comment #6
robertwb CreditAttribution: robertwb commentedComment #7
DanChadwick CreditAttribution: DanChadwick commentedRe #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....
Comment #8
robertwb CreditAttribution: robertwb commented@DanChadwick - sorry about the version confusion.
Per the HTML5 compatibility issue, I think this patch provides an appropriate workaround for the following reasons:
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"?
Comment #9
DanChadwick CreditAttribution: DanChadwick commentedOn 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.
Comment #10
robertwb CreditAttribution: robertwb commentedI 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:
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.
Comment #11
DanChadwick CreditAttribution: DanChadwick commentedThe 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.
Comment #12
robertwb CreditAttribution: robertwb commented@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.
Image 1: iPhone negative number support Safari.
Comment #13
DanChadwick CreditAttribution: DanChadwick commentedI 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.
Comment #14
robertwb CreditAttribution: robertwb commentedWorking 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?
Comment #15
DanChadwick CreditAttribution: DanChadwick commentedThe 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.
Comment #16
robertwb CreditAttribution: robertwb commented> 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?
Comment #17
DanChadwick CreditAttribution: DanChadwick commentedThis 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.
Comment #18
robertwb CreditAttribution: robertwb commentedSounds good. Thanks for the counsel.
Comment #19
fenstratClosing 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.