Fire HTML5 validation onblur

HTML & CSS
1

Hi guys,

I’m building a form that takes advantage of the new HTML5 validation methods where available. I have patterns set, required attributes etc. It all works great in supported browsers when the form is submitted, but I want to do the validation onblur. In accidentally found that I could trigger it early because on the postcode fields I have the following onblur code:


this.value = this.value.toUpperCase();

When I tabbed through those fields without entering anything (and they’re required fields) the form validated them as invalid. I want to do this on all fields. I thought there would be a validate() function that I could call for example, but that doesn’t appear to be the case. The only workaround I’ve found so far is:


this.value = this.value;

That fires the validation as I want it to, but it feels to bodgy to me. Is there a proper way to do it? I don’t care about browsers that don’t support the validation as this is an internal form and will be validated at the server anyway, I just want to support the latest versions of FF and Chrome that we use internally at work.

Cheers guys

2

If anyone stumbles across this thread and wants to know the answer, it’s really simple, and I found it on a Web Forms 2.0 page on the WHATWG site. The code is simply:

this.checkValidity()

So, I just did:

<input type="text" name="textInput" id="textInput" onblur="this.checkValidity();">

Job done. Thank you HTML5 and modern browsers!

3

Sounds nicer than waiting til the user hits submit, if the form is long.

4

According to the specification, if you just pass-through an input that is required and don’t enter anything, the validation doesn’t need to fire; only when you either enter something invalid or when you submit the form. I needed it to validate if you pass through a required field without entering anything too, so this is helpful for me. A required input is a required input after all!

Obviously the input in my example would have other arguments, like:

<input type="text" name="textInput" id="textInput" onblur="this.checkValidity();" pattern="(.){2,14}" required>

Which would validate only if between 2 and 14 characters (any in that example) are entered.

5

There are probably two specifications, unless the WHATWG and W3C are absolutely together on this one. But the required setting does or should fire onfocus, since it’s hooked up to the CSS :valid/:invalid settings (and I’m not a fan of that: I’m told I’m doing something wrong the moment I’m there, before I’ve even tried! I prefer onblur as well myself). Also Accessibility Technology are getting told onfocus that the input is invalid. I don’t really care for that either.

I find it funny that required doesn’t work really with pattern. At least not with CSS. Required seems to only check for empty strings, when you’d think it would check for whatever the input type or other attributes demand…

6

To be honest, I’m happy with how required works. I have to create some ridiculously complicated forms with some optional fields that have to meet certain requirements ONLY if they’re filled in, so I will set a pattern that says that there must be x characters of this pattern, but if it’s empty then I don’t want it to appear invalid. This is the behaviour that I am seeing in both FF and Chrome at present.

What is infuriating however is the way that Chrome/Chromium insists on adding commas to numbers, so my order number 123456 becomes 123,456 to the user. Not a massive problem because submitting it will submit 123456 but nevertheless, I don’t want it to display that way. Likewise, I can’t do any locale overrides for the date types, so I’m forced to have the YYYY-MM-DD format, which is not always what I need the user to enter.

As far as I’m concerned, it’s a REALLY positive step in the right direction, but it’s not perfect yet :slight_smile:

7

Oh, and I believe that WHATWG’s Web Forms 2.0 was merged in to W3Cs HTML5, but I may be wrong

8

When the W3C first decided to be a part of HTML5, they did that, yes. Initially both specifications were identical.

They’ve been diverging ever since though, and the forms section is it seems still being worked on. Especially the more problematic inputs like colour.

What is infuriating however is the way that Chrome/Chromium insists on adding commas to numbers, so my order number 123456 becomes 123,456 to the user. Not a massive problem because submitting it will submit 123456 but nevertheless, I don’t want it to display that way.

Yeah, imagine your user is Dutch and they think that’s 123.456 (one hundred twenty three wholes and four hundred fifty six thousandths). A dangerous assumption on the part of the browser. (Over here, 50 euros is displayed as €50,00 or €50,- so the decimal-comma problem is… a problem)

I dislike how Opera puts browser language error messages in the page. Apparently a huge pile of Javascript can override it, but, bleh. Or you add titles with your desired error message, which is bad since it still only appears UNDER Opera’s version and then you have titles muddying up your inputs and causing havok in screen readers.

Likewise, I can’t do any locale overrides for the date types, so I’m forced to have the YYYY-MM-DD format, which is not always what I need the user to enter.

Don’t forget month and week types if you can get away with them.
Supposedly, the users’ locale settings are supposed to adjust. So Americans whose system claims it’s in the US would allow MM-DD-YYYY while most others could get DD-MM-YYYY or whatever. Or, I remember Bruce Lawson and some others discussing this and supposedly that’s how it’s supposed to work.

The browsers are also supposed to be able to choose their own presentation of dates. While I don’t dislike Opera’s, I can’t imagine everyone wanting a jQuery-style date picker for every date. Similarly we haven’t moved over to type=date because we’re still using the back-ender’s wish of three separate select dropdowns. Was easier on his end for validation I think, not sure.

9

It may be supposed to do that, but I sure can’t get my Chrome, which is configured for the UK, to display DD-MM-YYYY, or DD/MM/YYYY as is sometimes necessary for the work that I’m doing. I know a lot of people would just do a day input, a month input and a year input, but in this case the form is used for debugging data sent in a SOAP request so I need to display it as the remote server expects it.

Oh, and I’m finding the title attribute being added to the end of the validation error message very useful for my purposes and in all honesty am unsure how it would work on a screen-reader, but since I don’t need to support those internally I guess it’s not a current issue. FF and Chrome both support those invalid messages now, so you get a “Please match the format requested: <title value>” in Chrome and “Please match the requested format: <title value>” in FF

10

Most screen readers will read out the title of an input, though there are differences on when and how. Mostly, if you have a complete error message in a title, you wouldn’t want someone to hear it the moment they land on the input, but ONLY if they screw it up.

Though placeholders may solve some of these issues, once it stops being so new and support is more standard. Ideally all screen readers would read a placeholder out as if it were a title, and usually for all users you can have a bit of “example data” sitting in it. Since browsers show the placeholder as a faded, low-contrast bit, it usually doesn’t trigger the user-tested “users won’t look at it or fill it in because it looks like it’s already been filled in” problem.

Once developers figure out how to override browser styling for those, I will imagine problems. Some will want to up the contrast simply to make it readable to more people, while others will have no idea about contrast problems or form usability problems, and just want to match site colours or whatever.

The future, it’s fun.

11

Right, I see what you mean about the title attribute in screenreaders. Personally, I used it to describe the data that I expect to go in that input, so I’d do something like:

<input type="password" ... title="Must be at least 7 characters, with at least one number">

As a completely pucked out of the ether example, so when it errors, the message comes up saying “Please match the requested format: Must be at least 7 characters, with at least one number”. It’s not perfect, but it seems acceptable to me. I don’t put something like “this is incorrect, fix it” for example.

12

Not very modern at all. If you were going to do it the modern way you’d get rid of the onblur from the HTML and add it from the JavaScript where it belongs.

13

Sigh. Yes, in reality, but for the sake of a simple example, I wrote what I wrote. I was just looking for the method

14

Antnee:
while normally I’d be more in favour of that title text either sitting in the label or in adjacent-to-the-input text (with an aria-describedby attribute on it), once most browsers show the title in their error messages I think what you have above could work pretty well most of the time.

My reasons for not favouring titles is that traditionally they’ve been mouse-based (and I figure if I bother giving a hint, I ought to give it to everyone). However here, you could argue it’s okay if keyboarders without screen readers don’t get the title text; if they screw up filling in the input, they’ll get that text in the error bubble.

Re inline javascript: looking at the type of script necessary to make, for example, the new <output> element even work, at all, I’d either have external Javascript create the element in the first place (which isn’t good actually, since apparently the “correct” use of output is where showing the value isn’t possible with the related input by default, meaning no <output>== the input is somewhat useless), or if it’s hard-written into the HTML I actually prefer the JS to sit in it.

Why? All the benefits you get from external Javascript don’t seem to apply here. The <output> doesn’t work at all without JS, the JS only ever does one thing (shows its input’s .value), and only works locally (right there). You could even argue that if you have a largish script slowly loading on the page, the this.value=input.value wouldn’t suffer that fate, and the rest of the form would function whether external scripts finished loading or not.

Meh. HTML5 has shown that HTML’s limits means in order to get some of that XForms goodness, Javascript becomes required. I dunno why browser vendors didn’t implement an in-the-browser method for <output> to work automatically with the association you give to its related input… maybe it wasn’t reasonably possible.