Skip to content

Spinner: Document that manually entered values are never modified - Fixe... #171

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Sep 6, 2013

Conversation

jzaefferer
Copy link
Member

...s #161

@@ -20,6 +20,8 @@

<p>Focus stays in the text field, even after using the mouse to click one of the spin buttons.</p>

<p>When the spinner is not read only, the user may enter a value via the text field that causes an invalid value (below min, above max, step mismatch, non-numeric input). Whenever a step is taken, either programmatically or via the step buttons, the value will be forced to a valid value (see the description for <a href="#method-stepUp"><code>stepUp()</code></a> and <a href="#method-stepDown"><code>stepDown()</code></a> for more details).</p>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"When the spinner is not read only"
"read only" as in the readonly HTML attribute?

"the user may enter a value via the text field that causes an invalid value"
This reads a little strange because "value" is included twice. Maybe something like "the user may enter an invalid value into the text field (below min, etc..." Just a suggestion.

@scottgonzalez
Copy link
Member

We should probably include an example of how to force a valid value on blur, with a note about potential usability issues when doing so.

@jzaefferer
Copy link
Member Author

Updated the wording, including a code example for the readonly attribute. I'm not sure right now how to force a valid value on blur.

@scottgonzalez
Copy link
Member

The value() method handles parsing and validation, but only when it's able to actually parse a value. So, you can check if a value is parseable by calling elem.spinner( "value" ). If you get back null, the value couldn't be parsed. However, getting a value just means the value is parseable, not that it's valid (there could be a step-mismatch or an out of range error). Setting the value will parse and validate the value. So if you pass a parseable, but invalid value, then the value will be adjusted to be the nearest valid value. However, if you pass a value that cannot be parsed, the value will be set as is.

We should probably add some more detail to the value() description to explain this.


Note: I thought that value() adjusted the value in addition to just parsing. I don't recall details from any discussions about this, so I'm not sure if this was intentional or an oversight. Do people think we should change the behavior? There are no unit tests checking the result when starting from an invalid value (at least changing the implementation caused no test failures).

@tjvantoll
Copy link
Member

So like http://jsfiddle.net/tj_vantoll/2bxRU, right?

I'm a bit torn. It would be nice to have a means of getting a valid value, but I would personally not expect value() to do this. I would expect to get what the <input> is displaying as a number (which is consistent with <input type="number">).

@scottgonzalez
Copy link
Member

@tjvantoll I think you forgot to save your changes. The fiddle is just a standard spinner.

@tjvantoll
Copy link
Member

@scottgonzalez
Copy link
Member

Ok, let's keep the current behavior.

@jzaefferer
Copy link
Member Author

I still don't know what to add to address "how to force a valid value on blur".

@scottgonzalez
Copy link
Member

var value = elem.spinner( "value" );
if ( value === null ) {
    elem.val( "" );
} else {
    elem.spinner( "value", value );
}

After discussing this in IRC, I think we actually shouldn't show how to do this, but instead just add an isValid() method: http://bugs.jqueryui.com/ticket/9542

@jzaefferer jzaefferer merged commit 54ca0f4 into master Sep 6, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants