Tags: validation

19

sparkline

Sunday, December 3rd, 2017

Monday, November 20th, 2017

Happier HTML5 Form Validation - daverupert.com

Dave uses just a smidgen of JavaScript to whip HTML5’s native form validation into shape.

Instead of being prescriptive about error messaging, we use what the browser natively gives us.

Wednesday, November 1st, 2017

Web Form Conundrum: disabled or readonly? | Aaron Gustafson

Good question! And a good answer:

If you really need it, which you probably don’t, readonly is what you want.

Wednesday, September 6th, 2017

Form Validation with Web Audio | CSS-Tricks

An interesting idea from Ruth—using subtle sounds to augment inline form validation.

There aren’t any extremely established best practices for this stuff. The best we can do is make tasteful choices and do user research. Which is to say, the examples in this post are ideas, not gospel.

Sunday, June 25th, 2017

Pure CSS crossword - CSS Grid

Form validation taken to the extreme. If you want to know more about how it was done, there’s an article explaining the markup and CSS.

Wednesday, March 22nd, 2017

Improve Your Billing Form’s UX In One Day – Smashing Magazine

A few straightforward steps for improving the usability of credit card forms. The later steps involve JavaScript but the first step uses nothing more than straight-up HTML.

Wednesday, November 16th, 2016

Usability Testing of Inline Form Validation: 40% Don’t Have It, 20% Get It Wrong - Articles - Baymard Institute

I saw Christian speak on this topic at Smashing Conference in Barcelona. Here, he takes a long hard look at some of the little things that sites get wrong when doing validating forms on the fly. It’s all good sensible stuff, although it sounds a bit medical when he takes about “Premature Inline Validation.”

Wednesday, October 12th, 2016

Enhancing a comment form: From basic to custom error message to BackgroundSync | justmarkup

This is a truly fantastic example of progressive enhancement applied to a form.

What I love about this is that it shows how progressive enhancement isn’t a binary on/off choice: there are layers and layers of enhancements here, from simple inline validation all the way to service workers and background sync, with many options in between.

Superb!

Sunday, January 3rd, 2016

Simple inline error message pattern

This is my go-to method for adding validation messages to forms—I think I first heard about it from Derek—so it’s nice to see it corroborated by Steve:

Add the error message as a child of the label element associated with an input.

Thursday, December 17th, 2015

Pseudo and pseudon’t

I like CSS pseudo-classes. They come in handy for adding little enhancements to interfaces based on interaction.

Take the form-related pseudo-classes, for example: :valid, :invalid, :required, :in-range, and many more.

Let’s say I want to adjust the appearance of an element based on whether it has been filled in correctly. I might have an input element like this:

<input type="email" required>

Then I can write some CSS to put green border on it once it meets the minimum requirements for validity:

input:valid {
  border: 1px solid green;
}

That works, but somewhat annoyingly, the appearance will change while the user is still typing in the field (as soon as the user types an @ symbol, the border goes green). That can be distracting, or downright annoying.

I only want to display the green border when the input is valid and the field is not focused. Luckily for me, those last two words (“not focused”) map nicely to some more pseudo-classes: not and focus:

input:not(:focus):valid {
  border: 1px solid green;
}

If I want to get really fancy, I could display an icon next to form fields that have been filled in. But to do that, I’d need more than a pseudo-class; I’d need a pseudo-element, like :after

input:not(:focus):valid::after {
  content: '✓';
}

…except that won’t work. It turns out that you can’t add generated content to replaced elements like form fields. I’d have to add a regular element into my markup, like this:

<input type="email" required>
<span></span>

So I could style it with:

input:not(:focus):valid + span::after {
  content: '✓';
}

But that feels icky.

Update: See this clever flexbox technique by Hugo Giraudel for a potential solution.

Friday, March 7th, 2014

Making progress

When I was talking about Async, Ajax, and animation, I mentioned the little trick I’ve used of generating a progress element to indicate to the user that an Ajax request is underway.

I sometimes use the same technique even if Ajax isn’t involved. When a form is being submitted, I find it’s often good to provide explicit, immediate feedback that the submission is underway. Sure, the browser will do its own thing but a browser doesn’t differentiate between showing that a regular link has been clicked, and showing that all those important details you just entered into a form are on their way.

Here’s the JavaScript I use. It’s fairly simplistic, and I’m limiting it to POST requests only. At the moment that a form begins to submit, a progress element is inserted at the end of the form …which is usually right by the submit button that the user will have just pressed.

While I’m at it, I also set a variable to indicate that a POST submission is underway. So even if the user clicks on that submit button multiple times, only one request is set.

You’ll notice that I’m attaching an event to each form element, rather than using event delegation to listen for a click event on the parent document and then figuring out whether that click event was triggered by a submit button. Usually I’m a big fan of event delegation but in this case, it’s important that the event I’m listening to is the submit event. A form won’t fire that event unless the data is truly winging its way to the server. That means you can do all the client-side validation you want—making good use of the required attribute where appropriate—safe in the knowledge that the progess element won’t be generated until the form has passed its validation checks.

If you like this particular pattern, feel free to use the code. Better yet, improve upon it.

Wednesday, January 30th, 2013

The test

There was once a time when the first thing you would do when you went to visit a newly-launched website was to run its markup through a validator.

Later on that was replaced by the action of bumping up the font size by a few notches—what Dan called the Dig Dug test.

Thanks to Ethan, we all started to make our browser windows smaller and bigger as soon as we visited a newly-launched site.

Now when I go to a brand new site I find myself opening up the “Network” tab in my browser’s developer tools to count the HTTP requests and measure the page weight.

Just like old times.

Wednesday, March 21st, 2012

Kicksend/mailcheck · GitHub

A handy little script that attempts to check email inputs for misspelled domain names. I’m pretty sure it doesn’t need to be written as a jQuery pug-in, though: anyone want to fork it and create a non-jQuery version too?

Wednesday, July 13th, 2011

HTML5Pattern

A handy list of regular expressions that you can use in the new pattern attribute on the input element in HTML5.

Friday, March 18th, 2011

Change Proposal for ISSUE-140 - WHATWG Wiki

An excellent zero-edit counter-proposal from Anne detailing why version numbers are unnecessary and undesirable for HTML.

Wednesday, November 10th, 2010

HTML5 Forms Validation in Firefox 4 - Mounir Lamouri's Blog

A quick run-through of some of the new HTML5 form features coming in Firefox 4.

Friday, October 27th, 2006

Documentation of the Programmatic Interface (API) to The W3C Markup Validation Service

The W3C Validator now has an API. It's SOAP only unfortunately, but this could still prove to be immensely useful for rolling into a CMS.

Monday, July 3rd, 2006

The unpushed envelope

Roger points to a survey by Sean Fraser that tests entries from the CSS Reboot for validation errors. The results (including exclamation marks) are:

71.8% of the websites failed validation for HTML Markup! for CSS! or, for both!

That is somewhat disheartening but at least it provides some grist for the mill for Joe’s failed redesigns.

Personally, I’m not as concerned about validation errors in CSS-based redesigns as I am by the prevalent mindset. Most reboots and redesigns invariably involve ripping all the markup out and rebuilding everything from scratch. So much for separating structure and presentation.

The CSS Zen Garden has been around for years now. It has succeeded in showing that CSS-based designs don’t need to be ugly. It’s also a testament to the fact that you can style the same markup document in completely different ways. But very few people seem to be making the most of this freedom.

In fact, the trend that I see in the myriad CSS galleries out there is a move towards more print-like designs that are very fixed and constrained. Even as, on the server side, the general shift seems to be towards a more open, user-defined flow of data, the front end attitude seems to be going in the opposite direction. Designers seem less willing to hand over more control to the user. How very Web 1.0.

Yes, I am talking about liquid layouts to a certain extent and yes, they are harder to implement well. Still, shouldn’t redesigns of personal sites (the bulk of CSS Reboot) be just the kind of place where we can embrace design challenges?

But this is about more than the hoary old fixed vs. liquid chestnut. It’s about recognising the potential of the tools we have at our disposal. CSS is perhaps the most remarkable tool of all. The ability to alter the presentation of a website without altering its structure should have opened up the floodgates of design creativity.

I’m not talking about subtle realignments either. I want to see sites that look different depending on the time of day, the location of the designer, or even the weather. Never mind device-independence, CSS provides everything-independence.

CSS hasn’t revolutionised web design. The reason lies not with the technology (which is revolutionary), but with the designers using it. Most designers have simply swapped the old technology (tables and font tags) for the new technology, without fully exploring what’s so completely new.

I’m as guilty as anyone. Having a web site that offers a choice of a handful of (mostly liquid) designs skins was a nice start when I first implemented it. Four years on, I was hoping for it be a passé idea. I don’t think that’s the case, sadly. But that’s no reason for me not to be exploring other avenues opened up by the power of CSS.

It’s almost as if CSS provides too much power. Maybe it makes designers uncomfortable. Perhaps that’s why the focus is on rounded corners, drop-shadows, wet-floor reflections and other graphical trends (bevel and emboss, anyone?) instead of seeing the bigger picture.

It’s a tired old cliché, but it’s true: design is about communication. It seems to me that a lot of web designers have conflated communication with control (in much the same way that marketeers confuse branding with perception).

I hope that things will change. I hope that some young guns will take up the challenge, stop following the crowd, and really push CSS to its fullest potential. I hope that the publication of a book like Transcending CSS will help inspire a new spirit of exploration. Don’t let me down, Malarkey.

Sunday, May 1st, 2005

Juicy Studio: Generic Form Validation Routine

A nice bit of unobtrusive DOM scripting for validating just about any form.