2026-07-18 08:00:00
One thing I like about 11ty is that common tasks for development oriented blogs are easily handled and syntax highlighting is no exception.
I installed the Syntax Highlighting Plugin just like the documentation asked me to. Then, I had to modify my code blocks in my blog post Markdown files to indicate what language they were. Thankfully, I had only written two articles so far that contained code blocks. Nothing so far deviates from what the documentation says.
When I started considering the compile process, however, I had a few considerations.
The first thing to note is that I inline my CSS. My thinking is that most users visiting my site aren’t likely to have my CSS file cached—either because they’re on my site for the first time or because it has been long enough since they visited my site and the file has expired.
Currently, I only have two templates: my universal template and my blog post template. I inline additional CSS in my blog post template that isn’t needed anywhere else on the site. As such, the first thing I did was add the PrismJS theme to my template and see how it looked. No surprise, it looked great.
But what if I have no code on the page? Why am I loading the CSS for every blog post? Easy enough. I added a yaml parameter of hascode: true. And then I check for that parameter in my template.
{% if hascode %}
<link rel="stylesheet" ... >
{% endif %}That was nice. But as I mentioned, why am I creating an HTTP request when I usually inline my CSS? No problem. A simple copy/paste and that was done.
Initially, because the themes are relatively small, I thought about finding a theme that worked for light mode and one for dark mode, wrapping them in prefers-color-scheme. But that still seemed excessive. I found the Duotone Light theme that I thought looked best for my light mode and then realized that much of it still worked in dark mode if I gave it a couple tweaks.
The first tweak was to use the light-dark declaration I had already had on my pre tags when I launched:
background: light-dark(#FFFFFF50, #00000050);I double-checked and noticed that the selector colour didn’t work in dark mode. So, instead of just trying to find a colour that would work, I decided to use a CSS colour function to solve the problem.
color: light-dark(#2d2006, hsl(from #2d2006 h s calc(l + 80)));This uses the hsl function to shift the luminosity of the colour from the light mode version.
This is a bit of overkill as I could just take the rendered colour and put that in place of the function but sometimes it’s just fun to try new things.
I really like how the code blocks look now, although I don’t love that there’s no indication that the code has overflowed the container if you have scrollbars turned off by default—which most people do these days. Once we get scroll-state container queries supported across all major browsers, maybe I’ll deal with it then.
2026-07-16 08:00:00
When I was building this site, I was keeping it lean but perhaps a bit messy. It’s not a big complex site and I didn’t need to write CSS to maintain a big complex site. As such, I even wondered if I’d stick to any kind of naming convention.
Old habits are hard to break and I found anytime I tried to get away with just element selectors for something, it was clunky as I continued to iterate. Sure enough, the more I worked on the site, the more I moved back to my modular ways. But ultimately, that’s neither here nor there. For a site like mine—written and maintained by one person—what kind of naming convention I use is nearly irrelevant. (I say nearly because I don’t want to be obtuse just for the sake of it!)
With my projects over the last few years, I’ve used a few different newer CSS features and have enjoyed what they can do. Here’s a few of the things I put into this site...
I originally used clamp on The Snook Nook for the site title at the top of the page. I wanted it to feel balanced regardless of screen width. I adjust both the font size and letter spacing in this case, so that the title always looked proportional.
For Snook.ca, I wanted something that was big and bold on a large screen but wouldn’t fill up an entire phone screen. Again, clamp came in clutch.
font-size: clamp(2em, 4vw, 4em)Clamp takes three values: the minimum, the preferred value, and the maximum. In this case, I wanted the font-size to be related to the screen width, which is where the vw units come in. The largest I wanted to go was 4em. This was eye-balled. There’s no special math here. Likewise, 2em still seemed reasonable on the bottom end and looked good for me.
I remember reading about this awhile back and it was a nice little thing to add to the site: text-wrap: balance. I just have it on the page title to avoid orphaned words and make them look a little more, well, balanced.
On the old site, I never loved how my headings looked over multiple lines because of the pencil lines I had on headings. As a result, I kept the titles shorter, on purpose. With this version, I wanted to get more creative with page titles, going longer if I needed to without it looking weird.
When Grid first came out, I was using it for larger, dynamic layouts like the restaurant grid on my Fifty site. Now, I find myself also using it for smaller elements. The article meta is a great example of this.
.meta {
display: grid;
justify-items: center;
}Boom. All the items are center aligned and stacked. I probably would've defaulted to trying to use display: flex here but that would've required an extra declaration to adjust the flex-direction to column. (And using align-items instead of justify-items.)
.meta-before:before {
content: "";
display:block;
width:50px;
padding-bottom: 5px;
border-top: 2px solid var(--green);
}The horizontal line is a pseudo-element that gets added into the grid stack before everything else. That border declaration leads me to the next thing.
The CSS isn’t large or anything but it was nice to use custom properties for easy colour management. I declared them on the root element. I could’ve probably just declared this on the html element itself just as easily.
:root {
--yellow: #FFCA00;
--green: #668800;
--white: #EFEFE6;
--black: #3C3C3C;
color-scheme: light dark;
}Again, I didn’t need multiple levels of abstraction. I just wanted something that made it easier to remember these hex codes and spit them out where I need them.
That last line in the previous example declares that my design supports light and dark mode and lets me use the light-dark function to easily declare colour options like this declaration for the body text.
color: light-dark(var(--black), var(--white));I’ve always just either toggled underlines on hover or toggled text colour. I don’t know when all the text-decoration options were added but I liked being able to do so.
a {
color: currentcolor;
text-decoration-thickness:2px;
text-decoration-color: var(--green);
}
a:hover { text-decoration-color: var(--yellow); }I was able to adjust the thickness and then change the colour on hover. I haven’t used the ol’ LVHA format in years but I might come back to it to give more useful visual clues for visited and active links.
The link colour just picks up whatever the light-dark colour is currently set.
I was really delighted by how easy it was to use all of these features and not have to be too concerned about cross browser issues. Looking through MDN was fun to discover what features I had missed over the years and could now implement reliably. Can I Use also continues to be a fantastic resource for verifying browser support.
2026-07-15 08:00:00
A week ago, I had launched this site using QuatroSlab for page titles and Google’s Slabo for body copy. For those that have been around awhile and are familiar with SMACSS, you might recognize QuatroSlab from that site. I like the font and started off with it to see how I’d feel about it on the this new design. Then I chose Slabo as a font that I felt paired well with it.
For the most part, I was fine with it but after finally getting a blog post written and posted under the new design, I was feeling less than thrilled with my choices.
Over yesterday and today, I decided to do some research on fonts and came across Pangram Pangram Foundry. They have some delectable fonts that make me want to do some interesting designs with them. This led me to Fragment. I looked through all the variants and Fragment Text felt just right for the body copy. It felt softer and rounder and more open and friendly than Slabo.
My only complaint is that I want some of the discretionary ligatures in the list of standard ligatures like the Th and ft. The rest of them are too much flourish for body copy. I enabled the ligatures for headings, at least, where some flourish is warranted.
For page headings, though, I wanted something bolder. This is where Pangram Pangram’s Pangaia comes in. I like the slightly retro-modern funky feel that this font brings to the table.
From a technical perspective, this is the first time I’ve taken advantage of OpenType feature capabilities and I found it confusing as I couldn’t find a good explanation of what liga or dlig or ss03 mean or how to know whether a font even supports these.
I’ve learned that you can turn these on or off via CSS’s font-feature-settings property.
font-feature-settings: "ss02", "ss03", "ss04", "dlig", "zero", "onum";Declaring the value turns them on. You can alternatively, specifically declare them on or off using the words on or off or the numbers 1 or 0. The following would enable features ss02, ss03, zero, and onum; it would disable ss04 and dlig.
font-feature-settings: "ss02" on, "ss03" 1, "ss04" off, "dlig" 0, "zero", "onum";The question then became about how to figure out which of these features exist in a particular font. For this, I used FontDrop!. It will show you what features are available and what those features look like for that font. FontDrop! is all client-side, too, which is nice. I didn’t want to be uploading files that aren’t mine to someone’s server.
I suspect I will end up tweaking which of these features are on or off as I add more content to the site and decide what works well for a given scenario.
2026-07-12 08:00:00
Welcome to the beginning. The end happened months ago but like many endings, sometimes they take awhile.
Snook.ca has, for the better part of the last 25 years, been mostly a professional outlet for me. What started out as “Technical Articles” turned into “a collection of tips, tricks, and bookmarks on web development” to just “Tips, Tricks, and Bookmarks on Web Development.” Stepping away from full time web design and development, I found myself writing more personal posts and changed the tagline to “Life and Times of a Web Developer” about a year ago or so to reflect that change.
On top of that, the design for the site had only changed marginally over the last 17 years. It was time for something new. I initially had some grand plans to push the limits of CSS or use some bleeding edge features as a way of stretching my dev skills that had gone somewhat dormant since the start of the pandemic. Instead, as I played with the design, I became more enamoured with simplicity—a better reflection of my personal life. (Ultimately, I also knew that if I made it too complex, I’d create roadblocks to wanting to work on the site.)
To start something fresh and new, I thought it best to put a bow on the old stuff and tuck it away. All of those old posts were and are aptly named Archives. It’s similar to how Jason Santa Maria or Rob Weychert have their site versioning: the content and design are set in stone. Everything as of April 2026 was converted into static pages, no longer powered by CakePHP.
The time between April and now has been spent cleaning up a bunch of the cruft that had built up over the years. It also included working on a new site design that I’d be happy enough to launch with and then continue to iterate on after it has gone live.
That’s technically where we are now. This is the inaugural post of the new site. If you’re reading this via RSS, that means the redirects are working. The journal is now called Everything and Nothing. It might be self evident but it’s because the journal is about everything and nothing. There are no categories like there were before. (Although I had all but removed the categories from the previous version. The URL was the only tell left.)
The design is a continued evolution of what came before. The “bookmark” in the header is now in tatters. The paper background and pencil lines are gone, leaving just a solid colour. The wavy lines are gone. The simple palette is still the same colours as before: the cream, the grey, and the green haven’t changed. I was able to finally get a dark mode added to the site, which is just the cream and the grey swapped. There's that simplicity again.
I also played with scroll-based animations using view-timeline. If you’re in Firefox, you can enable them in your settings. If not, the site works fine either way. Chrome and Safari support them. There’s some grid, @support, clamp and custom properties. Nothing ground breaking.
I decided not to have a main navigation. Mostly because it’s not necessary. Simplicity, yet again. My theory is that anybody who gets dropped into the middle of the site will go to the home page, if they go anywhere else at all.
Under the hood, I’m now using 11ty. I’ve used it for a few other projects and I like its approach. I’m familiar with it and I knew it would do what I needed it to do for this.
This design is an evolution and it will continue to evolve. This just marks the beginning. Or is it the end it’s marking? Or is it neither since this is just an evolution? Like a moth turning into a butterfly? gags How cliché.
Whatever it is, the site marches on. For those of you who consume via RSS and never click through, you’ll not see any different. The post frequency will continue to ebb and flow.
I’ve thought about consolidating things like the Photos and whisky reviews into the main site, allowing an easier way to weave all the pieces together, playing with themes built off the base design. That might happen.
Similar to the previous design that slowly changed over the years, this design, too, will slowly change as I add and remove and shift elements. This site is my playground, after all. As others have described their own sites, it’s my worry stone, my prayer beads. It provides me a place to practice my craft of design, development, and writing.
Importantly, it continues to provide a space outside of the algorithm, for myself and for others.
