Someone on Twitter saw fit to drive himself and others insane with a game that lets you guess the correct hex color code.
This is as strong a case as any for switching to HSL. Jesus…
Also, check out this talk by David DeSandro about how to actually read color hex codes. It’s cool as hell, but seriously, just use HSL instead.
Damn my laziness. If you happen to run macOS Mojave or iOS 13, you might’ve noticed that I added support for dark mode quite a while back. Silly ’ol me didn’t write about it, even though I was quite happy with myself for utilizing CSS custom properties to simplify the theming. Both Chris Ferdinandi and Jeremy Keith beat me to it (or rather, their posts got me to finally write at least something about it).
In the words of Mozilla Developer Network, the prefers-color-scheme CSS media feature is used to detect if the user has requested the system use a light or dark color theme. The spec is part of Media Queries Level 5 with a status of “Editors’s Draft” as of writing this post.
@media (prefers-color-scheme: dark) {
/* Dark styles goes here */
}
I’m just glad that we’re (mostly?) past vendor prefixes at this point.
To keep all things related to dark vs. light themes in one place, I leveraged the power of CSS custom properties. All colors that I use across the site is residing in a variables collection; /css/00_variables.css.
:root {
color-scheme: light dark;
--body-background: hsl(45, 40%, 94%);
--body-text: hsl(0, 0%, 20%);
}
@media only screen and (prefers-color-scheme: dark) {
:root {
--body-background: hsl(0, 0%, 20%);
--body-text: hsl(45, 40%, 94%);
}
}
This lets me keep only one instance of prefers-color-scheme: dark around, which is nice. All my other stylesheets just contain references to the custom properties.
body {
background-color: var(--body-background);
color: var(--body-text);
}
If you already utilize the cascade to its full potential, which luckily I have, you really shouldn’t need to change styles much. One such instance is the use of currentColor property value.
I never was a fan of using someone elses CSS reset, like Normalize or even Eric Meyer’s reset.css, but this modern take of a CSS reset caught my eye for several reasons.
In this modern era of web development, we don’t really need a heavy-handed reset, or even a reset at all, because CSS browser compatibility issues are much less likely than they were in the old IE 6 days. That era was when resets such as normalize.css came about and saved us all heaps of hell. Those days are gone now and we can trust our browsers to behave more, so I think resets like that are probably mostly redundant.
The reset for lists is frickin’ genius!
/* Remove default padding */
ul[class],
ol[class] {
padding: 0;
}
Why didn’t I think of that?
Extra bonus points for the piece by piece explanations for each section.
I just couldn’t leave that poor bookmarklet alone, could I? Using the previous version in the wild, I noticed some use cases where there was room for improvement. Right now my bookmarklet does two things:
<body> for any scroll disabling styling and tries to unset itposition: fixed or position: sticky and deletes themSounds good enough, right? Well, not quite. I found one big glaring issue with this; headers. Many times, modern websites use position: sticky for headers. If I delete them — well, then I’ve broken the site a little too much.
Based on my very scientific research following this, by visiting as many as ten websites, I could conclude the following:
position: fixed — these we can safely destroy with fireposition: fixed — these we want to keep, but away from scrolling viewThese assumptions (dangerous as assumptions may be), lead me to modify the script accordingly.
const elements = document.querySelectorAll('body *');
const body = document.querySelector('body');
if (getComputedStyle(body).overflow === 'hidden') {
body.style.overflow = 'unset';
}
elements.forEach(function (element) {
if (['-webkit-sticky', 'sticky'].includes(getComputedStyle(element).position)) {
element.style.position = 'unset';
}
else if(['fixed'].includes(getComputedStyle(element).position)) {
element.parentNode.removeChild(element);
}
});
I first check for position: sticky styled elements, and instead of removing them, I force the inline style to position: unset. This will reset to the initial value of position: static and so “un-sticky” any such elements on the page. Everything else that has position: fixed will instead just get deleted.
There are of course some caveats with this approach, mostly that older sites might still have sticky-ish headers that are positioned with the fixed property. I believe this is fine. Compared to the previous version, that just killed everything in sight, regardless of fixed or sticky, we now get something a bit more precise.
I’m beginning to have trouble coming up with good names for these bookmarklets, so this time around I’m just calling it “unSticky”. Besides, you’re completely free to name it whatever you wish.
Ok, that’s it for now. Let’s see how long I can leave this one alone.
Updated: Well that didn’t take long. My friend, Joacim de la Motte, decided to do some optimization for me. Apparently the IIFE is not really necessary, so I’ve removed it. The bookmarklet will still run without it.
Jeremy Keith writes:
I got an email recently from a young person looking to get into web development. They wanted to know what languages they should start with, whether they should a Mac or a Windows PC, and what some places to learn from.
I’ve gotten the question myself on more than one occasion; how should I get into front end development? Besides my recommendation of starting out with HTML, then moving on to CSS and lastly get into JavaScript, I often had to dig deep to find good sources for people to read that would help and inspire them. Thanks to Jeremy, that job has been done for me. From now on, I’ll link to his post.
I would like to add that Jeremy’s own excellent book “Resilient Web Design” should be part of the curriculum. Best of all is that it’s available for free online.
Thanks, Keith!