Make WordPress Core

Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#17863 closed task (blessed) (fixed)

HTML5 input type=number in admin settings

Reported by: niallkennedy's profile niallkennedy Owned by: georgestephanis's profile georgestephanis
Milestone: 3.4 Priority: normal
Severity: normal Version:
Component: Administration Keywords: needs-patch revert
Focuses: Cc:

Description

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.

Attachments (11)

discussion.diff (3.3 KB) - added by niallkennedy 13 years ago.
identify numeric inputs with input type=number in wp-admin/options-discussion.php
css-number.diff (1.6 KB) - added by joostdevalk 13 years ago.
CSS needed for input type="number"
17863.diff (20.1 KB) - added by garyc40 13 years ago.
An initial patch to get the ball rolling.
17863.preliminary.no-styling.diff (19.6 KB) - added by georgestephanis 13 years ago.
17863.all-but-admin-bar.diff (34.2 KB) - added by georgestephanis 13 years ago.
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.
17863-5.patch (27.5 KB) - added by azaozz 13 years ago.
Screen Shot 2012-03-15 at 12.40.22 PM.png (10.5 KB) - added by ryan 13 years ago.
Extra wide
Add New Post ‹ WordPress 3.1 — WordPress.png (14.4 KB) - added by batmoo 13 years ago.
Publish schedule inputs are squished
17863-schedule-inputs.diff (349 bytes) - added by batmoo 13 years ago.
Bump up the widths a bit
options-discussion.php.diff (1011 bytes) - added by trepmal 13 years ago.
change 'nested comment depth' field from <select> to type=number
options-writing.diff (1.3 KB) - added by kovshenin 13 years ago.
What about options-writing.php?

Download all attachments as: .zip

Change History (69)

@niallkennedy
13 years ago

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

#1 @azaozz
13 years ago

  • Milestone changed from Awaiting Review to Future Release

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.

#2 @joostdevalk
13 years ago

  • Cc joost@… added

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
13 years ago

CSS needed for input type="number"

#3 @nacin
13 years ago

  • Milestone changed from Future Release to 3.3

+1

#4 follow-up: @WraithKenny
13 years ago

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.)

#5 in reply to: ↑ 4 ; follow-up: @azaozz
13 years ago

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.

#6 in reply to: ↑ 5 @joostdevalk
13 years ago

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".

#7 @nacin
13 years ago

In [18762]:

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

#8 @scottconnerly
13 years ago

  • Cc scottconnerly added

See also #18763

#9 @nacin
13 years ago

  • Keywords needs-patch added; has-patch ui-feedback removed
  • Milestone changed from 3.3 to Future Release

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

#10 @carlospaulino
13 years ago

  • Cc carlospaulino added

#11 follow-up: @georgestephanis
13 years ago

  • Cc George@… added
  • Owner set to georgestephanis
  • Status changed from new to accepted

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)

#12 in reply to: ↑ 11 ; follow-up: @azaozz
13 years ago

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.

#13 in reply to: ↑ 12 @georgestephanis
13 years ago

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.

#14 @azaozz
13 years ago

  • Milestone changed from Future Release to 3.4
  • Severity changed from minor to normal

Lets get some more html5 enhancements in 3.4.

#15 @sabreuse
13 years ago

  • Cc sabreuse@… added

@garyc40
13 years ago

An initial patch to get the ball rolling.

#16 @garyc40
13 years ago

  • Keywords has-patch added; needs-patch removed

#17 @georgestephanis
13 years ago

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
13 years ago

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.

#18 @azaozz
13 years ago

  • Type changed from enhancement to task (blessed)

@azaozz
13 years ago

#19 @azaozz
13 years ago

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

#20 follow-up: @nacin
13 years ago

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.

#21 in reply to: ↑ 20 @azaozz
13 years ago

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).

#22 @azaozz
13 years ago

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".

#23 @azaozz
13 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In [20168]:

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

#24 @nacin
13 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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".

#25 follow-up: @toscho
13 years ago

  • Cc info@… added

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.

#26 in reply to: ↑ 25 ; follow-up: @azaozz
13 years ago

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.

#27 @nacin
13 years ago

  • Keywords needs-patch revert added; has-patch removed

#28 follow-up: @georgestephanis
13 years ago

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/association-of-controls-and-forms.html#attr-fs-novalidate

Last edited 13 years ago by georgestephanis (previous) (diff)

#29 in reply to: ↑ 28 @azaozz
13 years ago

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...

#30 @ryan
13 years ago

That's with Chrome on OS X.

Last edited 13 years ago by ryan (previous) (diff)

#31 follow-up: @nacin
13 years ago

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.

#32 in reply to: ↑ 31 @toscho
13 years ago

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.

#33 follow-up: @nacin
13 years ago

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.

#34 in reply to: ↑ 33 @azaozz
13 years ago

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.

#35 @nacin
13 years ago

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.

#36 @nacin
13 years ago

In [20199]:

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

#37 @nacin
13 years ago

In [20200]:

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

#38 @nacin
13 years ago

In [20201]:

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

#39 @nacin
13 years ago

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

#40 @nacin
13 years ago

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.

#41 @nacin
13 years ago

In [20203]:

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

#42 in reply to: ↑ 26 @nacin
13 years ago

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.

#43 @nacin
13 years ago

In [20204]:

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

@batmoo
13 years ago

Publish schedule inputs are squished

#44 follow-up: @batmoo
13 years ago

  • Cc batmoo@… added

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

@batmoo
13 years ago

Bump up the widths a bit

#45 follow-up: @azaozz
13 years ago

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.

#46 in reply to: ↑ 45 ; follow-up: @nacin
13 years ago

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.

#47 in reply to: ↑ 46 @azaozz
13 years ago

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).

#48 in reply to: ↑ 44 ; follow-up: @azaozz
13 years ago

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).

#49 in reply to: ↑ 48 ; follow-up: @georgestephanis
13 years ago

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.

#50 in reply to: ↑ 49 @azaozz
13 years ago

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; }.

#51 @azaozz
13 years ago

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.

#52 @azaozz
13 years ago

In [20217]:

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

#12 follow-up: @nacin
13 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In [20289]:

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

@trepmal
13 years ago

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

#14 @trepmal
13 years ago

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?)

#15 @ocean90
13 years ago

trepmal, you should open a new ticket for this.

@kovshenin
13 years ago

What about options-writing.php?

#17 @kovshenin
13 years ago

  • Cc kovshenin@… added
Note: See TracTickets for help on using tickets.