On Tue, 09 Oct 2012 21:29:45 -0700, S Page spage@wikimedia.org wrote:
Some MediaWiki forms have elements with type=email. Up until 2 weeks ago, en-wiki would strip that out as it's invalid in old-school HTML. But now that $wgHtml5 is true, it flows to the browser.
A nifty result is mobile browsers will use a custom on-screen keyboard with @ and .com in it for type=email. A new result is HTML5 browsers will not submit a form with an invalid e-mail in it. A strange result is, Special:ChangeEmail [1] already does client-side validation of e-mail, so users on HTML5 browsers get duelling tooltips! (See screenshot [2] attached to Bug 40909 [3].)
Other MediaWiki forms that use Html or HTMLForm to specify HTML5 field types will also have behavior changes. If you don't want the browser's validation, Munaf Assaf figured out you can disable it [4] or you can sort-of override the styles for the browser's validation tooltip [5]. Does anyone have experience of doing client-side validation in conjunction with the browsers' own validation? Ideally a jQuery plug-in would build up client-side validation on top of the browser's HTML5 support while hiding their big differences in implementation.
Bind an event handler for the browser's 'invalid' event. When fired use e.preventDefault() and apply your own invalid form input styling. Canceling the event will not disable the browser's validation (the form will still not be submitted) but it will disable the browser UI allowing you to do the styling yourself.
It would actually be nice to re-do our validation. I'd like to see more of our forms that validate input using things like required and pattern to do validation that works using native UI when JS is disabled.
The ideal would probably be: - Our server side form setups that do validation will provide ways to declare simple validation like required and pattern (as opposed to only offering a validity callback). These we will start exposing natively. - We offer a wrapper lib around the native validation API perhaps with some extras to abstract away some of the things about validation that aren't exposed natively. (eg: I'm thinking well probably want a custom way to define a validation callback instead of individual code having to manually listen to input. Also there's probably no 'valid' event to remove custom UI) - In that wrapper lib we include a shim that will implement pattern and require handling in place of the native browser in browsers that haven't implemented the form validation API yet. - The lib will include a way to do custom validation so we don't need other code to do that. - We should also take the notion of "Expensive validation" into account in the api. Some type of custom validation that depends on something expensive like a HTTP call so we have a native way to ask to fire an expensive validation callback with a promise but only after the library delays waiting to make sure the user isn't still typing the stuff in. - Using that expensive validation callbacks we should offer the option in some of our form defining code to automatically run a server side validation callback in the same form that defined the form output. Using that we could define a single username validation method that would automatically do server side form validation, output validation errors server side, and at the same time be used by a client side callback to tell you that the username is reserved before you even submit the form. (Though this might require an entirely new Form api anyways) - On top of that lib we'll include an extra MW specific lib that cancels out the native UI and does validation UI the way we're planning with the style guide (https://www.mediawiki.org/wiki/Style_guide/Forms) - We'll have a way for individual skins to hook into that lib so they can override the way that the form validation UI is done.
In the absolute ideal. Even all our custom validity will be done entirely using the wrapper lib around the native form validation. Such that if for some reason we do not load the lib in charge of using the wrapper lib to create our custom validation UI (or if a skin finds some way to say it does not want us to load that UI) the entire system still works by using the browser's native validation UI.
Thanks in advance,
[1] https://en.wikipedia.org/wiki/Special:ChangeEmail [2] http://bug-attachment.wikimedia.org/attachment.cgi?id=11173 [3] https://bugzilla.wikimedia.org/show_bug.cgi?id=40909 [4] http://www.w3.org/TR/html5/attributes-common-to-form-controls.html#attr-fs-n... [5] http://jsfiddle.net/trixta/qTV3g/