Color is pretty good for separating things. That's what your basic pie chart is, isn't it? You tell the slices apart by color. With enough color contrast, you might be OK, but you might be even better off (particularly where accessibility is concerned) using patterns, or a combination.
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></a> link (with a valid
href attribute) 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.
I could probably list about 100 reasons, since as a founder, user, and (ahem) PRO member of CodePen myself, I'm motivated to do so. But let me just list a few here. Some of these are my favorites, some are what PRO members have told us are their favorite, and some are lesser-known but very awesome.
It wasn't long ago when Mikael Ainalem's Pen demonstrated how you might use SVG outlines in HTML then lazyload the image (later turned into a webpack loader by Emil Tholin). It's kind of like a skeleton screen, in that it gives the user a hint of what's coming. Or the blur up technique, which loads a very small image blurrily blown up as the placeholder image.
Accessibility is an aspect of web development that is often overlooked. I would argue that it is as vital as overall performance and code reusability. We justify our endless pursuit of better performance and responsive design by citing the users, but ultimately these pursuits are done with the user's device in mind, not the user themselves and their potential disabilities or restrictions.
A responsive app should be one that delivers its content based on the needs of the user, not only their device.
Luckily, there are tools to help alleviate the learning curve of accessibility-minded development. For example, GitHub recently released their accessibility error scanner, AccessibilityJS and Deque has aXe. This article will focus on a different one: Ally.js, a library simplifying certain accessibility features, functions, and behaviors.
We've covered Aspect Ratio Boxes before. It involves trickery with padding such that an element's width and height are in proportion to your liking. It's not an ultra-common need, since fixing an element's height is asking for trouble, but it comes up.
One way to lower the risk is The Psuedo Element Tactic, in which a pseudo element pushes its parent element to the aspect ratio, but if the content inside pushes it taller, it will get taller, aspect ratio be damned.
You can use that technique in CSS grid with grid items! Although there are a couple of different ways to apply it that are worth thinking about.
I recently learned about a browser feature where, if you provide a special HTTP header, it will automatically post to a URL with a report of any non-HTTPS content. This would be a great thing to do when transitioning a site to HTTPS, for example, to root out any mixed content warnings. In this article, we'll implement this feature via a small WordPress plugin.
User interfaces can be expressed by two things:
- The state of the UI
- Actions that can change that state
From credit card payment devices and gas pump screens to the software that your company creates, user interfaces react to the actions of the user and other sources and change their state accordingly. This concept isn't just limited to technology, it's a fundamental part of how everything works:
For every action, there is an equal and opposite reaction.
- Isaac Newton
When you use a bit of inline
<svg> and you don't set
width, but you do set a
viewBox, that's a fitwigoo. I love the name.
The problem with fatwigoo's is that the
<svg> will size itself like a block-level element, rendering enormously until the CSS comes in and (likely) has sizing rules to size it into place.
It's one of those things where if you develop with pretty fast internet, you might not ever see it. But if you're somewhere where the internet is slow or has high latency (or if you're Karl Dubost and literally block CSS), you'll probably see it all the time.
I was an offender before I learned how obnoxious this is. At first, it felt weird to size things in HTML rather than CSS. My solution now is generally to leave sensible defaults on inline SVG (probably icons) like
height="20" width="20" and still do my actual sizing in CSS.
Petr Gazarov published a pretty rad little design pattern in his article Text input highlight, TripAdvisor style.
It's a trick! You can't really make an
<input /> stretch like that, so Petr makes a
<span></span> to sync the value too, which acts as the border itself. The whole thing is a React component.
If you're willing to use a
<span contenteditable></span> instead, you could do the whole thing in CSS!