Page MenuHomePhabricator

Allow input min/max form validation attributes when browser support is there/can be polyfilled
Closed, ResolvedPublic

Description

These were blacklisted because there were apparently (WebKit) browsers that blocked submission for invalid values, but didn't make it clear the user why.

Testing with http://jsfiddle.net/hLceeL4m/2/ , Firefox 30.0 and Chromium 35.0.1916.153 seem to work fine.

Safari 7 seems to let you submit, which is not compliant, but also not a confusing UX the way the original problems were.

Safari 8 is coming out soon with Yosemite, so that and Opera should be tested.


See Also:
T72974: maxlength html form values are not used in preferences
T25769: Password fields for account creation are marked as required when they are not

Details

Reference
bz71026

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:55 AM
bzimport set Reference to bz71026.
bzimport added a subscriber: Unknown Object (MLST).
Jdforrester-WMF set Security to None.

I don't know if this is a mac only issue, but it looks fine to me on opera 43 (windows 10).

opera_2017-03-14_12-58-59.png (184×350 px, 8 KB)

matmarex subscribed.

It seems that they're already allowed. Tested with forms like this:

HTMLForm::factory( 'ooui', [ 
  'foo' => [ 
    'type' => 'int', 
    'min' => 5, 
    'max' => 7, 
  ] 
], $this->getContext() );

HTMLForm::factory( 'div', [ 
  'foo' => [ 
    'type' => 'int', 
    'min' => 5, 
    'max' => 7, 
  ] 
], $this->getContext() );

They result in HTML like this:

<input step="1" type="number" tabindex="0" name="wpfoo" value="" min="5" max="7" id="ooui-php-1" class="oo-ui-inputWidget-input webfonts-changed">

<input id="mw-input-wpfoo" name="wpfoo" size="20" min="5" max="7" step="1" type="number">