- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 29 Dec 2010 06:41:19 +0000 (UTC)
On Mon, 20 Sep 2010, Shiv Kumar wrote: > > We now have the option define if an element is required and the form > will validate the value such elements before submission. That's a step > in the right direction. However, it so happens different implementation > do different things in the case when the validation return false. There are differences that are allowed by the spec, and differences that aren't. > Some browsers, have no visual indication (probably due to lack of > support at this time) There has to be some user notification (though it doesn't have to be visible), per spec. > Some browsers will outline the field in question That's allowed. > Some will pop up a message under the field in question. That's allowed. > The message is something cryptic like "You have to specify a value". That doesn't seem that cryptic... > I'd like to propose that we have a validationMessage attribute (or some > other name) that allows web developers to specify a more appropriate > (based on the type of input data required and/or the input type such as > text, url, email etc.), user friendly/business friendly and creative > error message rather than some unknown message (as different vendors > will likely have their own verbiage). If the author wants to specify a custom error message, then the setCustomValidity() API can be used. > That's one aspect I'd like to talk about. The other aspect is that > typically, you don't want to show only one error as a time to the end > user. You want to show them all validation errors after trying to submit > the form one time (this is the common practice as well), rather than > forcing them to submit a form multiple times to discover validation > issues one by one. As you can imagine this is a nightmare for the > end-user. User agents are allowed to indicate multiple problems at once. > For the second scenario I guess the spec should be clear about > validating all fields? I'm not sure what the spec for this is (I can't > seem to find anywhere that details the validation process for forms). http://www.whatwg.org/specs/web-apps/current-work/complete.html#interactively-validate-the-constraints On Tue, 21 Sep 2010, Shiv Kumar wrote: > > On a web page/form, I'm asking the user to enter her social security > number and she sees a message "You have to specify a value", you're > saying that sounds ok to you? Oh, and the next browser will say > something like, "This is a required field". What then? Assuming that the field with no value is highlighted and the user agent tells the user that a value is required, it seems pretty straightforward. > I guess what I'm saying is there should be ways to hook into all of > this. That will give people the option to do their own thing but using > the plumbing that's in place. I'm really not asking the browser UI > implementation. I think we should have a scriptable/event driven way to > hook into all this. There are a bunch of toolkits that do this and allow > one to hook into the process, making it customizable. If it's not > customizable, it's not useful for the majority. There are a number of hooks, including the 'invalid' event, the setCustomValidity() method, and the rest of the constraint validation API. On Wed, 22 Sep 2010, Aryeh Gregor wrote: > > I take it back. Firefox and Opera do give different results, but the > bug in Firefox (if it is one) is subtler. This works as I expect in > both: > > data:text/html,<!doctype html> > <form> > <input name=x required oninvalid=" > this.setCustomValidity(''); > if (!this.validity.valid) { > this.setCustomValidity('abcd'); > } > " onfocus="this.setCustomValidity('')"> > <input type=submit> > </form> For ideal results, you really want to call setCustomValidity() in oninput (or onforminput if it depends on other fields also), not oninvalid. (Calling setCustomValidity('') with the empty string in oninvalid in particular is definitely wrong, since the validity is checked before the event is fired, not after.) On Wed, 22 Sep 2010, Mounir Lamouri wrote: > > And, FTR, I think I do not think it's a good think to use > setCustomValidity() _only_ to put your own message in there. This should > be used when the validity rule isn't one of those specified. For > example, if you want two password fields to be the same, you can use > setCustomValidity() because there is no way to specify that with the > current constraint validation API. Indeed. > I don't think people should promote the use of setCustomValidity() to > override a pre-defined message with a more custom one like changing > "Please fill this field." by "Please, set a username.". But that's just > an opinion... It certainly would be ideal for pages to rely on the UA for this, since they'll get better over time that way. But if they want to do it, it isn't completely inappropriate. :-) On Wed, 22 Sep 2010, Jonas Sicking wrote: > > I agree with what Mounir says. I think using setCustomValidity to > override the error message that the page displays is an abuse of API. I dunno if I'd go as far as abuse. > However I do think it is an interesting use case to be able to use the > browser UI to display a custom error message. Consider > > <input type=email name=username required maxlength="100"> > > If the user leaves this empty, firefox will (in beta7) display the > message "Please fill out this field.". And if the user enters something > that isn't a valid email address, we'll display the message "Please > enter an email address.". But if the user types an email address longer > than 100 characters, we'll display the message "Please shorten this text > to 100 characters or less (you are currently using 105 characters)" > > However for the former situation, the website might want to use the > message "Please choose a user name", and for the latter "Your user name > must be a valid email address, we use this to contact you when we have > product updates". Right. > One way to do this would be to make the "invalid" event implement an > interface with a function like setCustomErrorMessage(in DOMString > message). This string would then be displayed by the UA in its UI > wherever it displays validation error messages. > > I actually think that the customerrormessage attribute that has been > suggested is a decent solution too. It does mean that you have to do > some trickery if you want to display different error messages for > different types of errors, but nothing too bad. All you'd need to do is > install an event handler for the "invalid" event, and in that handler do > something like element.setAttribute("customerrormessage", myMessage); If you're setting an error message, what's wrong with setCustomValidity()? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 28 December 2010 22:41:19 UTC