HTML5 input type=number in admin settings

[niallkennedy]

There has been some discussion and tickets around HTML5 inputs, the proper time to introduce changes, and fallback support for browsers not able to take full advantage of the changes. I'd like to start with a relatively simple change: identifying input fields in settings that expect a number.
​http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#number-state
​http://www.miketaylr.com/code/html5-forms-ui-support.html

I would like to accomplish a few things:

• Move input validation to the client instead of waiting for an error on save. If there is an option to close comments after X days I would like to restrict input to characters 0-9; modern browsers can help.
• Communicate minimum or maximum values on the settings page. If we know the backend is going to reject a value over 20 we can restrict the input in the browser to try and help the administrator provide better input values.
• Trigger input helpers such as an up-down arrows in browsers with extra UI help for numbers. iOS brings up a numeric keypad instead of a keyboard for example.
• Fallback behavior is input type=text, same as now.

CSS rules for input type="text" would have to change to include input type="number" for UI consistency.

Attached is a patch for wp-admin/options-discussion as an example.

[niallkennedy]

identify numeric inputs with input type=number in wp-admin/options-discussion.php

[azaozz]

There are many places where we can take advantage of HTML 5 and CSS 3. All form fields, selected, focus, transitions (instead of JS), etc. However IMHO we should introduce them when we drop IE7. This is the last of the "old" browsers that we currently support.

[joostdevalk]

Since input type="number" is just treated as input type="text" in browser that do not support it, I don't see why we'd have to wait. We're using border-radius on several things already, that doesn't show for some people either, we don't really care, do we?

Number is probably the simplest to implement in a lot of pages, I'm using it in several plugin backends and the people that notice love it and no issues have come up, so I agree, this should just be done now :)

I'll attach a patch to apply the same styling as we have for type=text inputs to type=number inputs.

[joostdevalk]

CSS needed for input type="number"

[nacin]

+1

[WraithKenny]

Agreed with joostdevalk, these are progressive enhancement.

(We only have to wait for IE7/IE8 EOL in order to support the new html5 elements without JavaScript.)

[azaozz]

Replying to WraithKenny:

(We only have to wait for IE7/IE8 EOL in order to support the new html5 elements without JavaScript.)

Unfortunately IE8 EOL is still far in the future. It's the last IE version supported in win XP and there are huge amount of XP users despite it's EOL.

[joostdevalk]

Replying to azaozz:

Unfortunately IE8 EOL is still far in the future. It's the last IE version supported in win XP and there are huge amount of XP users despite it's EOL.

Luckily, that doesn't matter. It's progressive enhancement, it'll just function as it does now when the browser doesn't support input type="number".

[nacin]

In [18762]:

Provide styling to HTML5 text-like inputs (email, number, search, tel, url). see #17863.

[scottconnerly]

See also #18763

[nacin]

The CSS is there for people to use. Let's start implementing the new input types in 3.4.

[georgestephanis]

CC'ing myself as a reminder to go through and submit a patch for 3.4 to migrate input types across to HTML5 standards.

They also do really good things for Mobile Browsers (more useful keyboards and the like)

[azaozz]

Replying to georgestephanis:

Thinking we should make this IE8 no-js compatible, perhaps adding a class with the input type and styling on that. So instead of input[type="number"] we would do input.number, etc.

[georgestephanis]

Replying to azaozz:

The purpose for this isn't to add in some additional styling for input types, it's to use the input types themselves. The only reason styling was mentioned is that (I believe) Webkit adds some undesired styling to input type="number" that needs to be compensated for.

One of the primary advantages of using type="url" type="email" type="tel" and type="number" is that on mobile devices (tablets/phones) that have soft keyboards will normally provide the user a custom keyboard based on the input field type. Phone numbers get a phone keypad. Emails normally have the @ sign included in the keyboard somewhere. URLs may have a .com button included.

In doing this, it will make the admin panel a _lot_ more user-friendly for people on mobile devices, as well as the summum bonum-s of being more semantic and forward thinking without sacrificing -any- backwards compatibility. This is purely progressive enhancement. Nothing whatsoever will display worse than existing in older versions of IE.

[azaozz]

Lets get some more html5 enhancements in 3.4.

[garyc40]

An initial patch to get the ball rolling.

[georgestephanis]

Here's what I had in my first dry-run -- I think you caught a few I missed, I'll review and merge them together over the weekend or on Monday after I get the styling in place.

Do we want to leave the up and down arrows on webkit's type="number" fields, or should those be stripped off?

I also need to include some CSS to overwrite the default styling that webkit applies to type="search" fields.

[georgestephanis]

Merged in all new input types found so far, added in step="" min="" max="" as appropriate, added styling as needed and tidied up search type a bit to maintain WP aesthetics.

[azaozz]

Refreshed 17863.all-but-admin-bar.diff, removed several type=url as it limits the input to absolute URLs only.

[nacin]

I have seen home and siteurl be relative, so that definitely can't be type=url either.

It would be best if there was an option-by-option accounting for everything in the patch, why the type makes sense, and why the min, step, and Max were chosen (or omitted). We have all seen curious uses of options and I would hate for one of these to cause a regression.

I would be happy to commit this but my commit message will be a long accounting of the individual changes, potentially multiple commits, not a short message.

[azaozz]

Replying to nacin:

Agreed. It's nice to have "self-validating" fields but we need to double-check that validation.

As far as I understand the specs for type=number, the min, max and step attributes are used in validation (when present), so field with step="10" won't accept values like 12, 123, etc.

The type=search doesn't seem to have any restrictions, and type=url is limited to absolute URLs only.

There are also several field types that deal with date/time and couple of "more interesting" types, like range that displays a slider and color that brings up swatches or the system color picker (Opera only for now).

[azaozz]

Revised the patch. Removing almost all type="url" as there's no need to limit most of these fields to absolute URLs. The only remaining is in options-media.php for "Full URL path to files" (when specifying alternate wp-content/uploads directory).

In a nutshell:

• All search fields changed to type="search" (no validation restrictions).

• All fields that are for emails changed to type="email".

• The following fields changed to type="number" step="1" min="1":
  • screen.php, screen options "per page",
  • options-discussion.php, "Break comments into pages...",
  • options-discussion.php, "Hold a comment in the queue if it contains %s or more links",
  • options-media.php, all fields for setting thumbnail, medium and large sizes for images,
  • options-media.php, both fields for setting "embed size" for auto-embedded videos,
  • options-reading.php, "posts_per_page" and "posts_per_rss",
  • class-wp-list-table.php, "Current page", also removed the esc_attr( 'paged' ) from there, no point in escaping a hard-coded ASCII string.

• The "Automatically close comments on articles older than..." field in options-discussion.php changed to type="number" step="1" min="0".

• The "Site Upload Space Quota" field in ms.php changed to type="number" step="0.1" min="0".

• The year, day, hour, minute fields in template.php changed to validate the corresponding numbers, i.e. for day: type="number" step="1" min="1" max="31".

[azaozz]

In [20168]:

Set proper HTML5 input types in the admin, props georgestephanis, fixes #17863

[nacin]

There's no requirement for upload_url_path to be an absolute URL.

I'm wondering if some of the type="number" step="1" min="1" should instead be min="0".

[toscho]

type=email will be validated different in various browsers. See ​http://jsfiddle.net/nimbu/hqrzK/ for a test with IDN domains: Works in Opera, fails in Chrome (17.0.963.78 m) and Firefox (10.0.2). May not be backwards compatible or not compatible with plugins that override email validation.

[azaozz]

Replying to nacin:

There's no requirement for upload_url_path to be an absolute URL.

Perhaps the "label" should be fixed there too. "Full URL path..." doesn't sound right if a relative URL can be used.

I'm wondering if some of the type="number" step="1" min="1" should instead be min="0".

Image dimension settings (in options-media.php) and number of items (posts/comments) per page cannot be 0 (zero). That would reset these fields to the default number. Perhaps 0 can be user as "reset to default" setting there (the browsers also accept empty fields for type="number" that would reset to default).

Replying to toscho:

type=email will be validated different in various browsers... (IDN) Works in Opera, fails in Chrome (17.0.963.78 m) and Firefox (10.0.2).

Seems that IDN email addresses currently fail validation in the back-end. The benefit of having type="email" is that on mobile devices when the field is focused the onscreen keyboard would contain the @ button. On the other hand we shouldn't be using "buggy" email address validation, perhaps better to revert these fields and test again in 3.5, hopefully Chrome and FF will get that right by then.

[nacin]

#20217

[georgestephanis]

If the issue is the client-side validation causing problems for some elements, we can have the best of both worlds. Leave the input type="url" to get the proper keyboard for mobile and such, but add a novalidate attribute to the element.

This will turn off browser-based client side validation.

For more on this, ​http://www.w3.org/TR/html5/forms.html#attr-fs-novalidate

[azaozz]

Replying to georgestephanis:

...Leave the input type="url" to get the proper keyboard for mobile and such, but add a novalidate attribute to the element.

Yes, we should probably do that. On the other hand there seem to be a lot of differences between the browsers with the new input types. Starting to think we should wait some more time before implementing them...

[ryan]

Extra wide

[ryan]

That's with Chrome on OS X.

[nacin]

When type="number" is set, size="2" is ignored. And thus, you end up with ryan's screenshot. So, we can set max values (not preferable), add the small-text class to limit it to about 60px, or change them back to type="text".

I think type="number" works well in a few places, such as on options-discussion.php, where it looks nice and appears to be helpful. However, it has caused visual issues in a few other places, obviously. I am going to review each change from the perspectives of both code and UI, and will probably revert some.

There is a UX consideration here as well. The pagination input only works when you hit enter after changing the value. Type type enter is much better than click click enter. It's not like clicking the up arrow refreshes the page via ajax — you still have to go to the keyboard, as there's no button. So those should be type="text" for the time being.

[toscho]

Replying to nacin:

I am going to review each change from the perspectives of both code and UI, and will probably revert some.

We could add pattern="\d+" instead to help users to enter valid values – validation without UI changes.

[nacin]

In [20196]:

Revert type="email" (HTML5) as some browsers that do validation on these fields do not work for IDN domains yet. Core does not support these well either, but server-side validation can at least be dealt with by a plugin. see #17863.

[azaozz]

Replying to nacin:

Revert type="email" (HTML5) as some browsers that do validation on these fields do not work for IDN domains yet.

Was thinking we could try @georgestephanis' suggestion to add novalidate for type="url" and type="email". Then all mobile devices would show the right keyboard when these fields are focused but we won't be limiting the user input there. Will do some tests with that.

[nacin]

In [20198]:

Remove type='number' from list table page inputs out of a concern for UX, as well as styling issues. fixes #20247. see #17863 for further discussion.

[nacin]

In [20199]:

Adjust site upload space HTML5 type='number' validation. see #17863.

[nacin]

In [20200]:

comment_max_links may be zero to bypass the moderation check entirely. [20168] erred. see #17863.

[nacin]

In [20201]:

Only grow input.small-text if type='number'. see [20168], see #17863.

[nacin]

[20199] — We are going to need to novalidate these (as well as others).

[nacin]

In [20202]:

It is possible for comments_per_page to be 0, which turns off pagination. See sanitize_option(); wp_list_commnts(); get_comment_link(). see #17863.

[nacin]

In [20203]:

Size options on options-media.php are allowed to be 0 or otherwise empty. see #17863.

[nacin]

Replying to azaozz:

Replying to nacin:

There's no requirement for upload_url_path to be an absolute URL.

Perhaps the "label" should be fixed there too. "Full URL path..." doesn't sound right if a relative URL can be used.

Sounds correct to me. We want the full URL path (/wp-content/uploads). "Full path" could mean a fileystem path. In fact we explicitly don't want it to be an absolute URL; see wp_upload_dir().

---

In making the decisions in [20196] [20198] [20199] [20200] [20201] [20202] [20203] I simply consulted the code, both for sanitize_option() and whether any validation or resetting occurred in core code. In many cases, a field may be left blank or 0 and it is treated specially, such as with a fallback, or by turning off something (like paging, or comment moderation link counting). We need to be careful here.

[nacin]

In [20204]:

upload_url_path is a relative URL path, not an absolute URL. Remove type='url' as that enforces absoluteness. see #17863.

[batmoo]

Publish schedule inputs are squished

[batmoo]

The post schedule inputs are a bit squished because of the added browser chrome.

[batmoo]

Bump up the widths a bit

[azaozz]

Replying to nacin:

... In fact we explicitly don't want it to be an absolute URL; see wp_upload_dir().

Maybe we are reading that differently but in wp_upload_dir() we do:

if ( !$url = get_option( 'upload_url_path' ) ) {
  if ( empty($upload_path) || ( 'wp-content/uploads' == $upload_path ) || ( $upload_path == $dir ) )
    $url = WP_CONTENT_URL . '/uploads';
  else
    $url = trailingslashit( $siteurl ) . $upload_path;
}

which seems to expect upload_url_path to be an absolute url and if empty it sets it to an absolute url (WP_CONTENT_URL is the absolute url to wp-content).

In making the decisions in [20196] [20198] [20199] [20200] [20201] [20202] [20203] I simply consulted the code, both for sanitize_option() and whether any validation or resetting occurred in core code. In many cases, a field may be left blank or 0 and it is treated specially, such as with a fallback, or by turning off something (like paging, or comment moderation link counting). We need to be careful here.

Agreed. It is more of a UX question if we should consider entering 0 (zero) to be the same as leaving the field empty. Since that's the current behavior in many places perhaps it's better to leave it as is.

[nacin]

Replying to azaozz:

which seems to expect upload_url_path to be an absolute url and if empty it sets it to an absolute url (WP_CONTENT_URL is the absolute url to wp-content).

You're correct — we don't "explicitly don't want it to be an absolute URL" as I wrote. However, it *can* be a relative URL, and things will work fine.

[azaozz]

Replying to nacin:
Ah, my bad. Thought we were trying to get the users to enter an absolute url there, but as you mention root relative urls work fine so that shouldn't be restricted.

Testing the novalidate attribute, seems we can use it on email fields to bypass the IDN validation problem and still show the @ key on mobile devices. May also need to use it on the "upload space" fields as setting a number field to step="10" would show validity error for numbers that aren't evenly dividable by 10 (i.e. can't enter 75, has to be 70 or 80).

[azaozz]

Replying to batmoo:

The post schedule inputs are a bit squished because of the added browser chrome.

Yes, there's #20217 to address that. Thinking the consensus is to revert that for now as making the fields wider is... oogly(er) (also they would have to be even wider to display correctly in all browsers/OS combinations).

[georgestephanis]

Replying to azaozz:

Replying to batmoo:

The post schedule inputs are a bit squished because of the added browser chrome.

Yes, there's #20217 to address that. Thinking the consensus is to revert that for now as making the fields wider is... oogly(er) (also they would have to be even wider to display correctly in all browsers/OS combinations).

We could just use CSS to hide the number scroll buttons.

​http://stackoverflow.com/questions/3975769/disable-webkits-spin-buttons-on-input-type-number

Keep the keyboard on mobile, but don't allow any UI changes.

Alternately, we can add a class or data-mobiletype="number" attribute and use JS to change the actual type on mobile browsers (building off the mobile/touch browser detection I included in #20014)

Just my 2c.

[azaozz]

Replying to georgestephanis:

We could just use CSS to hide the number scroll buttons.

Perhaps but it needs to address all browsers (currently WebKit and Opera, soon FF). Also if I remember correctly some css there can freeze/crash some versions of Chrome, so... Maybe better not to use css hacks for that.

Keep the keyboard on mobile, but don't allow any UI changes.

That seems to circle back to having a way to detect all mobile devices/browsers from PHP (the current $is_iphone global works for most but not all). Then it would be as easy as setting these fields to type="number" only when on mobile and having the css input[type="number"] { width: whatever; }.

[azaozz]

Don't think we can set type="url" and/or type="email" and skip validation. The novalidate attribute is only for <form> and formnovaludate is only for <input type="submit" ...>, both turn validation off for the entire form, no per-field setting.

However both don't work in current Safari. Wasn't able to determine if new version of Safari that supports these would be coming out soon.

It seems this has to be revisited in WP 3.5 or 3.6.

[azaozz]

In [20217]:

Revert type="number" for the date/time fields as it introduces UI/styling issues, fixes #20217, see #17863

[nacin]

In [20289]:

Remove step="" from upload size inputs, as the step is enforced in the spec, rather than being a recommendation. finally fixes #17863.

[SergeyBiryukov]

Related: #20420

[trepmal]

change 'nested comment depth' field from <select> to type=number

[trepmal]

Didn't see a reason for the threaded/nested comment depth field to have not been converted to type=number.
Patch above, in case it was just missed. (Should I have opened a new ticket for this patch?)

[ocean90]

trepmal, you should open a new ticket for this.

[ocean90]

Related: #20526

[kovshenin]

What about options-writing.php?