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.
Andy and I have put a lot of work and thought into Every Layout. We want it to be the best resource it can be. Naturally, we would like to be paid for the value we are giving you. However, we know that not everyone can afford the things they’d like to have. We’re trying to address this in two ways:
- A large selection of free content, including all of the “rudiment” articles that cover the basics of (our take on) contemporary CSS
- An honor system, wherein you can claim to be eligible for the full Every Layout for free
What makes you eligible for (2)? If you are currently out of work, you are a full-time student or under 19 years old, you are trying to get your first job as a web developer or designer, or you are an unpaid volunteer for a charitable organization not involved in proselytism: consider yourself a match. Also, if you are the sole person of your ethnicity, gender, or sexual orientation at your company or in your local developer community: we will gift Every Layout to you. If you have a disability that makes accessing equivalent resources difficult, you can have this resource for free. We are trying to make it as accessible as possible.
It would be logistically and ethically implausible for us to vet, or otherwise judge, if you deserve to have Every Layout without a charge. If you believe you fit into the criteria above, let us know. That’s the honor part.
Are we suckers? Perhaps, to some. But while you alone decide if you qualify, we decide if you disqualify. That is, if we see you saying or sharing racist, homophobic, transphobic, sexist, or fascist sentiments, or you’re caught engaging in what we consider, in any way, punching down, you get fuck all for free from us.
There are many design considerations for making your content more accessible to all. Some things to think about and build into your design workflow include:
- Choose a common font that most users have encountered before.
- The “serif vs. sans-serif debate” is not a huge deal if you choose a common font family or one that has unique characters.
- Avoid specialty display fonts or font families that are not unique (ex. letters or numbers that could mirror each other).
- Your fonts should have a minimum size of 14px (ideally more) and when coded should use relative values.
- Pay attention to color and contrast! Use tools to check the ratio between the text and background and be wary of gray.
- Don’t rely on color alone to signify information (ex. “click on the red button”).
- Clearly define paragraph and letter spacing.
- Do not let the overall width of the content exceed 80 characters (40 characters for logograms).
- Avoid paragraph alignment (such as justified) which creates whitespace within the content.
In the mid-nineties, Laurence Peter Deutsch and colleagues at Sun Microsystems devised a list of what they called The Fallacies of Distributed Computing. These were a list of common assumptions that developers working on distributed systems were prone to making; mistakes that would impact the reliability, security, or resilience of their software. Those fallacies are as follows:
- The network is reliable.
- Latency is zero.
- Bandwidth is infinite.
- The network is secure.
- Topology doesn’t change.
- There is one administrator.
- Transport cost is zero.
- The network is homogeneous.
Reading over the eight fallacies listed out so plainly, they seem so obvious and clear that you’d struggle to believe that anyone would ever fall foul of them: of course we know bandwidth isn’t infinite! The thing is, these fallacies are obvious, but they don’t exist to teach us anything new; they exist to remind us of the fundamentals. Nor are they intended to explain or describe normal condition; they’re intended to remind us of worst case scenarios. They’re not saying that the network is always unreliable, or that latency is always high, or that bandwidth is always low: they’re saying that, sometimes, one or all of them will be sub-optimal. We should prepare for that.
Yet time and time again I see developers falling into the same old traps—making assumptions or overly-optimistic predictions about the conditions in which their apps will run. Developers frequently tell me things likemost of our users are on wifi, or4G is pretty much everywhere now, orpeople only ever visit the site from inside the office anyway. Even if this is statistically true—even if your analytics corroborate the claim—planning only for the best leaves you utterly unprepared for the worst. To paraphrase Jeremy, it’s not about how well it works, but how well it fails.
If you’re looking for an example of exactly what not to do in terms of front-end performance, I can’t think of a better one than this - they threw away a lot of the performance optimizations browsers give us for free in a bizarre attempt at improving page loading, which ended up doing the opposite:
- immediately applying
display: none;to the
- waiting until the very last of the page’s images had arrived;
- once they’d arrived, removing the
display: none;and gradually fading the page into visibility.
Not only does this strike me as an unusual design decision—setting out to build a lazyloader and then having it intentionally block rendering—there had been no defensive strategy to answer the question: what if something goes wrong with image delivery?
‘Something wrong’ is exactly what happened. Due to an imperfect combination of:
- images being completely unoptimised, plus;
- a misconfiguration with their image transformation service leading to double downloads for all images;
…they’d managed to place 27.9MB of images onto the Critical Path. Almost 30MB of previously non-render blocking assets had just been turned into blocking ones on purpose with no escape hatch. Start render time was as high as 27.1s over a cable connection1.
If you’re going to build an image loader that hides the whole page until all images are ready, you must also ask yourself what if the images don’t arrive?
As a blind screen reader user, and in my career educating designers, developers, and testers on accessibility issues, I have had the opportunity to observe the techniques used by various users to understand the layout and operation of web pages and applications. I have also seen well-intentioned sighted testers believe that components or entire sites are not accessible because they were unfamiliar with the techniques of navigating the web without sight.
In this article, I will walk you through the ways a blind screen reader user can navigate a web page, gather information about its layout and organization, and use that knowledge to efficiently and rapidly navigate a site or application. I hope to convey the importance of using techniques other than the TAB key as a primary means of navigating a website and illustrate the power you provide to a screen reader user by following semantic HTML markup and the principles of the Web Content Accessibility Guidelines.
Two years ago, I wrote about
prefers-reduced-motion, a media query introduced into Safari 10.1 to help people with vestibular and seizure disorders use the web. The article provided some background about the media query, why it was needed, and how to work with it to avoid creating disability-triggering visual effects.
We’re now four months into 2019, and it makes me happy to report that we have support for the feature in all major desktop browsers! Safari was first, with Firefox being a close second. Chrome was a little late to the party, but introduced it as of version 74.
Reduce isn’t necessarily remove
We may not need to throw the baby out with the bathwater when it comes to using animation. Remember, it’s
If the meaning of a component is diminished by removing its animation altogether, we could slow down and simplify the component’s animation to the point where the concept can be communicated without potentially being an accessibility trigger.
Even though Microsoft has explicitly told the world to stop using Internet Explorer 11, many organizations still have a significant enough IE11 user base that they have no choice but to build their products to acquiesce to the aging browser’s idiosyncratic demands.
Whether you are new to the world of building the front-end for Internet Explorer 11 compatibility or you are an old hand who knows their way around all the IE11 pitfalls, read on to learn more about:
- Choosing the right environment for debugging
- Tackling CSS layout issues
- Understanding the IE11 debugger
Armed with these tips, one should be able to quickly solve problems in the instance when a web application works perfectly on everything but IE11.