WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 2 years ago

Last modified 2 years ago

#17863 closed task (blessed) (fixed)

HTML5 input type=number in admin settings

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

Download all attachments as: .zip

Change History (69)

niallkennedy3 years ago

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

comment:1 azaozz3 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.

comment:2 joostdevalk3 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.

joostdevalk3 years ago

CSS needed for input type="number"

comment:3 nacin3 years ago

  • Milestone changed from Future Release to 3.3

+1

comment:4 follow-up: WraithKenny3 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.)

comment:5 in reply to: ↑ 4 ; follow-up: azaozz3 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.

comment:6 in reply to: ↑ 5 joostdevalk3 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".

comment:7 nacin3 years ago

In [18762]:

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

comment:8 scottconnerly3 years ago

  • Cc scottconnerly added

See also #18763

comment:9 nacin3 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.

comment:10 carlospaulino2 years ago

  • Cc carlospaulino added

comment:11 follow-up: georgestephanis2 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)

comment:12 in reply to: ↑ 11 ; follow-up: azaozz2 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.

comment:13 in reply to: ↑ 12 georgestephanis2 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.

comment:14 azaozz2 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.

comment:15 sabreuse2 years ago

  • Cc sabreuse@… added

garyc402 years ago

An initial patch to get the ball rolling.

comment:16 garyc402 years ago

  • Keywords has-patch added; needs-patch removed

comment:17 georgestephanis2 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.

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

comment:18 azaozz2 years ago

  • Type changed from enhancement to task (blessed)

azaozz2 years ago

comment:19 azaozz2 years ago

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

comment:20 follow-up: nacin2 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.

comment:21 in reply to: ↑ 20 azaozz2 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).

comment:22 azaozz2 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".

comment:23 azaozz2 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

comment:24 nacin2 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".

comment:25 follow-up: toscho2 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.

comment:26 in reply to: ↑ 25 ; follow-up: azaozz2 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.

comment:27 nacin2 years ago

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

comment:28 follow-up: georgestephanis2 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/forms.html#attr-fs-novalidate

Version 1, edited 2 years ago by georgestephanis (previous) (next) (diff)

comment:29 in reply to: ↑ 28 azaozz2 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...

ryan2 years ago

Extra wide

comment:30 ryan2 years ago

That's with Chrome on OS X.

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

comment:31 follow-up: nacin2 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.

comment:32 in reply to: ↑ 31 toscho2 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.

comment:33 follow-up: nacin2 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.

comment:34 in reply to: ↑ 33 azaozz2 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.

comment:35 nacin2 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.

comment:36 nacin2 years ago

In [20199]:

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

comment:37 nacin2 years ago

In [20200]:

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

comment:38 nacin2 years ago

In [20201]:

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

comment:39 nacin2 years ago

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

comment:40 nacin2 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.

comment:41 nacin2 years ago

In [20203]:

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

comment:42 in reply to: ↑ 26 nacin2 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.

comment:43 nacin2 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.

batmoo2 years ago

Publish schedule inputs are squished

comment:44 follow-up: batmoo2 years ago

  • Cc batmoo@… added

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

batmoo2 years ago

Bump up the widths a bit

comment:45 follow-up: azaozz2 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.

comment:46 in reply to: ↑ 45 ; follow-up: nacin2 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.

comment:47 in reply to: ↑ 46 azaozz2 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).

comment:48 in reply to: ↑ 44 ; follow-up: azaozz2 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).

comment:49 in reply to: ↑ 48 ; follow-up: georgestephanis2 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.

comment:50 in reply to: ↑ 49 azaozz2 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; }.

comment:51 azaozz2 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.

comment:52 azaozz2 years ago

In [20217]:

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

comment:12 follow-up: nacin2 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.

trepmal2 years ago

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

comment:14 trepmal2 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?)

comment:15 ocean902 years ago

trepmal, you should open a new ticket for this.

comment:16 ocean902 years ago

Related: #20526

kovshenin2 years ago

What about options-writing.php?

comment:17 kovshenin2 years ago

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