Journal tags: validation

I’m at day two of Indie Web Camp Brighton.

Day one was excellent. It was really hard to choose which sessions to go to because they all sounded interesting. That’s a good problem to have.

I ended up participating in:

• a session on POSSE,
• a session on NFC tags,
• a session on writing, and
• a session on testing your website that was hosted by Ros

In that testing session I shared some of the bookmarklets I use regularly.

Bookmarklets? They’re bookmarks that sit in the toolbar of your desktop browser. Just like any other bookmark, they’re links. The difference is that these links begin with javascript: rather than http. That means you can put programmatic instructions inside the link. Click the bookmark and the JavaScript gets executed.

In my mind, there are two different approaches to making a bookmarklet. One kind of bookmarklet contains lots of clever JavaScript—that’s where the smart stuff happens. The other kind of bookmarklet is deliberately dumb. All they do is take the URL of the current page and pass it to another service—that’s where the smart stuff happens.

I like that second kind of bookmarklet.

Here are some bookmarklets I’ve made. You can drag any of them up to the toolbar of your browser. Or you could create a folder called, say, “bookmarklets”, and drag these links up there.

Validation: This bookmarklet will validate the HTML of whatever page you’re on.

Validate HTML

Carbon: This bookmarklet will run the domain through the website carbon calculator.

Calculate carbon

Accessibility: This bookmarklet will run the current page through the Website Accessibility Evaluation Tools.

WAVE

Performance: This bookmarklet will take the current page and it run it through PageSpeed Insights, which includes a Lighthouse test.

PageSpeed

HTTPS: This bookmarklet will run your site through the SSL checker from SSL Labs.

SSL Report

Headers: This bookmarklet will test the security headers on your website.

Security Headers

Drag any of those links to your browser’s toolbar to “install” them. If you don’t like one, you can delete it the same way you can delete any other bookmark.

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 Kitty Giraudel for a potential solution.

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.

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.

Open link to post on cool new site. Resize browser window—tiny, huge, tiny. Don’t read essay. Realize. Hang head in shame.I blame @beep.

— Frank Chimero (@fchimero) January 29, 2013

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.

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.