I recently embarked on improving the client-side form validation for a client. There were about 400 lines of form validation code stuffed inside a 1000 line
form_helper.js. I looked for lightweight form validation scripts but after some hemming and hawing I decided to try my hand (again) at native HTML5 Form Validation.
If you’ve ever experimented with HTML5 Form Validation, you’ve probably been disappointed. The out-of-box experience isn’t quite what you want. Adding the
requiredattribute to inputs works wonderfully. However the styling portion with
input:invalidsorta sucks because empty inputs are trigger the
:invalidstate, even before the user has interacted with the page.
I finally sat down and spent a couple days trying to make HTML5 Form Validation work the way I want it. I had the following goals:
- Leverage browser-level feedback, free focus management and accessible labelling
- Only validate inputs on submit
- Styling with
With this wishlist in hand, I set off and found a solution that works with only 6 lines of code.
These snippets are my attempt to save and organize various bits of code, best practices, and resources relating to web development and design. They also function as a to do list of sorts, for things I want to implement in my own code, but haven’t yet. The concept is inspired by Jeremy Keith’s links and CSS-Tricks, among other things. Enjoy.
Recently, Chromium improved their implementation of
navigator.connectionby adding three new attributes:
Before that, the available attributes were
type. With these two attributes you couldn’t really tell if the connection was fast or slow. The
navigator.connection.typemay tell us a user is using WiFi, but this doesn’t say anything about the real connection speed, as they may be using a hot spot and the connection is in fact 2G.
With the addition of effectiveType we are finally able to get the real connection type. There are four different types (slow-2g, 2g, 3g and 4g) and they are described this way by the Web Incubator Community Group:
slow-2g: The network is suited for small transfers only such as text-only pages.
2g: The network is suited for transfers of small images.
3g: The network is suited for transfers of large assets such as high resolution images, audio, and SD video.
4g: The network is suited for HD video, real-time video, etc.
Let’s see how we can improve user experience by delivering images based on available connection speed.
Every now and then, I like to revisit Vannevar Bush’s classic article from the July 1945 edition of the Atlantic Monthly called As We May Think in which he describes a theoretical machine called the memex.
A memex is a device in which an individual stores all his books, records, and communications, and which is mechanized so that it may be consulted with exceeding speed and flexibility. It is an enlarged intimate supplement to his memory.
It consists of a desk, and while it can presumably be operated from a distance, it is primarily the piece of furniture at which he works. On the top are slanting translucent screens, on which material can be projected for convenient reading. There is a keyboard, and sets of buttons and levers. Otherwise it looks like an ordinary desk.
1945! Apart from its analogue rather than digital nature, it’s a remarkably prescient vision. In particular, there’s the idea of “associative trails”:
Wholly new forms of encyclopedias will appear, ready made with a mesh of associative trails running through them, ready to be dropped into the memex and there amplified. The lawyer has at his touch the associated opinions and decisions of his whole experience, and of the experience of friends and authorities.
And now I’m using the World Wide Web, a hypermedia system that takes in the whole planet, to create an associative trail. In this post, I’m linking (without asking anyone for permission) to six different sources, and in doing so, I’m creating a unique associative trail. And because this post has a URL (that won’t change), you are free to take it and make it part of your own associative trail on your digital memex.
The topic of disabling links popped up at my work the other day. Somehow, a “disabled” anchor style was added to our typography styles last year when I wasn’t looking. There is a problem though: there is no real way to disable an
<a>link (with a valid
hrefattribute) in HTML. Not to mention, why would you even want to? Links are the basis of the web.
At a certain point, it looked like my co-workers were not going to accept this fact, so I started thinking of how this could be accomplished. Knowing that it would take a lot, I wanted to prove that it was not worth the effort and code to support such an unconventional interaction, but I feared that by showing it could be done they would ignore all my warnings and just use my example as proof that it was OK. This hasn’t quite shaken out for me yet, but I figured we could go through my research.
First, things first:
Just don’t do it.
A disabled link is not a link, it’s just text. You need to rethink your design if it calls for disabling a link.
Surefire way: remove the href
If you have decided that you are going to ignore my warning and proceed with disabling a link, then removing the
hrefattribute is the best way I know how.
Straight from the official Hyperlink spec:
areaelements is not required; when those elements do not have
hrefattributes they do not create hyperlinks.
An easier to understand definition from MDN:
This attribute may be omitted (as of HTML5) to create a placeholder link. A placeholder link resembles a traditional hyperlink, but does not lead anywhere.
- page being left between requesting the base image and the script/noscript image
- browsers that pre-load pages they incorrectly predict you will visit
- network errors, especially on mobile devices
- any undoubtedly many more I haven’t even thought about…
I’m passionate about image performance optimisation and making images load fast on the web. One of the most interesting areas of exploration is placeholders: what to show when the image hasn’t loaded yet.
During the last days I have come across some loading techniques that use SVG, and I would like to describe them in this post.
I think this is a good example of the is-ought problem in philosophy, transplanted into the world of software development:
A/B testing is a great way of finding out what happens when you introduce a change. But it can’t tell you why.
I used the site earlier in the year, and actually felt my heart rate increase. Never again.
— Paul Robert Lloyd (@paulrobertlloyd) October 24, 2017
The problem is that, in a data-driven environment, decisions ultimately come down to whether something works or not. But just because something works, doesn’t mean it’s a good thing.
If I were trying to convince you to buy a product, or use a service, one way I could accomplish that would be to literally put a gun to your head. It would work. Except it’s not exactly a good solution, is it? But if we were to judge by the numbers (100% of people threatened with a gun did what we wanted), it would appear to be the right solution.
Dark Patterns are tricks used in websites and apps that make you buy or sign up for things that you didn’t mean to. The purpose of this site is to spread awareness and to shame companies that use them.