On Tue, 09 Oct 2012 21:29:45 -0700, S Page <spage(a)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.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]