Building momentum with some simple CSS
07 October 2020
Sticking with the theme of leaving this project much longer than
intended, I finally got back to making some progress.
My other work has seen me buried in writing CSS lately, so I thought
that a good way back in would be to put together a simple
stylesheet to move the site away from the browser defaults.
However, my approach to writing CSS has changed since the last time I
wrote about it. Longterm readers may recall how I wrote enthusiastically about
Tachyons back in
2016. Since then, TailwindCSS has taken the development world by storm
and that's pretty much what I've been using since – even purchasing the TailwindUI library of components.
It's been a very comfortable framework to use — once you've got
whatever build tool you're using all set up. To be clear, getting a
TailwindCSS setup working "just so" is not a trivial exercise, but the
benefits always felt worth it.
That was until I needed to work on a project that had a shared "core"
with multiple, variable implementations. This approach wasn't just for
business logic but design too. Each application needed to look
similar, even sharing some pages, but each needed to be "reskinned" to
use brand colours, fonts, etc.
"Oh easy!" I thought, "This is what CSS was designed for, I'll just use the cascade or some
custom properties to apply different styles". Turns out it
wasn't so easy... I ended up having the same variables declared in the
Tailwind config and in CSS custom properties. I started getting into
specifity issues — something I had even forgotten was a thing!
— and struggled to make the changes in each application without
upsetting the shared core. I could feel myself being
torn between how Tailwind works and how CSS is supposed to work.
By treating CSS as single-purpose utility classes, all with
equivalent specifity Tailwind had removed one of CSS' biggest pitfalls
but also removed it's biggest strength. Tailwind is popular with JS
developers because it suits the way their applications are built with
CSS that is scoped to localised components, but
CSS is fundamentally about the cascade — it's in the name after
I went back to writing BEM-based CSS which is how I did things prior
to the atomic approaches. I was immediately reminded how clumsy and
verbose it was, but only because my CSS skills had dulled. I had
gotten lazy and failed to see the big picture which is vital to
writing good CSS. Instead of writing generic
.media-object-type classes, I was writing incredibly
specific classes for single elements — much like I was still
styling with Tailwind.
Enter Andy Bell
I searched around trying to find some direction and remembered I had
bookmarked 'Every Layout' a while back but not really
looked into it. The idea is that it provides a textbook example of how to build
every primative layout you'll likely need for any website. There were
the usual suspects like centering items and the good 'ol media object,
but I wasn't prepared for what I found.
Looking through the free layouts didn't much inspire me, but when I
read the 'Rudiments' series of articles that accompany the layouts, it
was a complete revelation. In five short articles, Andy explained how
CSS was designed to be used and how to embrace this rather than fight
it. I've been doing frontend development for eight years now and these
five articles taught me more than all the blog posts and books I've
I won't enumerate all of the concepts behind this was of writing CSS
and instead I encourage you to read his work both on
Every Layout and his own site, Picalil.li where he expands
these ideas to a more formal methodology he calls CUBE CSS.
By all means, take a look at the source code of this site, either
here in the browser, or on GitHub and see for yourself
how much you can do with very little CSS!
Writing a brief
10 July 2020
Been a little longer than I said it would hasn't it?! Never
I like to start a new project by roughing out a brief of some
kind. It's never too long and detailed as I like to be able to
take advantage of the things I learn along the
way, but there needs to be some direction. I find
that stating the requirements, examining the shareholders of
the project and perhaps identifying some constraints or possible
issues early are all that's needed. Once I get started I tend to
use Basecamp's Shape Up process to build each
feature or requirement. This gets me out of the gate and building
something "real" quickly.
The Brief in brief
Post articles — I'd obviously like to be able
to write. Articles will be pretty varied in length – some pretty
long! – so I'd like to provide in-article navigation.
Post 'photosets' — Photography has always
been my thing. I've flirted with professional photography a few times
but much prefer to "go amateur". I don't use Instagram
anymore but would still like a place to share individual photos and
also larger "photosets" that tell a story and are accompanied by a few
- Going with the grain of the web — This will
mean using proper, semantic HTML markup with all the attributes
required to be a11y and SEO friendly. Using HTML for markup, CSS
for styling and JS only where necessary. A bonus of this
approach is that it should be fast and work well for years without suffering
- Static pages — For the defacto "about" and
- Lists — I'd like to experiment with public
watching/reading/listening lists. Something that also occured to
me was consolidating the hundreds of browser bookmarks that I
don't really look at (even though I saved these pages for a
reason, so should!) into a public reference on different
- HTML caching — Static sites are great...until
they aren't. I can get pretty far with my likely web stack of
choice (more on that later) but adding full HTML caching will
take a lot of load off the application if I ever get a spike in
- RSS & JSON feeds — I'm ashamed to say that
my site has never had either. Something I'd like to rectify
Other features I'm considering
Private posts — To navigate around my
avoidance of social media it might be nice to share articles and
photosets that only select people like family and friends can see.
This will require a lot of work relative to the results so may ultimately
end up on the never-ending back burner.
Email digests — I'd like people to be able to sign up for email digests at
regular intervals (for example once per week, once per month or
as new posts are made) without using a newsletter provider like
Mailchimp. By building it myself I can keep user's email
addresses out of a third party's hands and automate the content
of each email.
Objectives & Constraints
Tool-less front end development
I initially thought it might be a good idea to explore
"precompilation" as the driving
concept of the software design; optimising the deliverables as much as possible ahead of any requests.
However, static sites and tools like Webpack are pretty much end game in this regard and I've
been down that road before. I found that going 100% static actually creates as
many problems as it solves, and that there's real value to
having a running application behind a site, even if it *could* get
overwhelmed in a traffic spike.
I'm also a bit tired of all my CSS and JS needing a
compilation step. I've become a big fan of StimulusJS and TailwindCSS, but
to get the best out of them you really need to be using Webpack.
This isn't the end of the world because at this point I've already
sunk the time into understanding it. However, I always feel
uncomfortable adding it to a project – it just feels fragile and
brittle – and open up the project to a world of
npm and a huge
Instead, I'd like to concentrate on writing and delivering
human-readable code without a compilation step where possible. This
improves the value of the code as a learning resource both for me and
any one that chooses to take a look at the source code. That was how I
— and many other developers my age — learnt to build websites.
Besides, I don't intend to use much JS so Webpack would primarily have
been concatenating files and optimising images in a single command.
This is something that
MAKE or even a simple bash script
along for the ride.
Is a database "right" for content?
Representing content as data rather than markup allows for templates to generate the
precise HTML required, whilst also keeping design and content as
distinct entities — something that's important if you ever want
to update the design without migrating your past content to a new
Changes to content shouldn't (always) require changes to templates and
vice versa. In reality however, the two are dependant on each other
and ultimately using a markup language like HTML or Markdown provides
a much clearer idea of the content and how it will be displayed. The
cherry on top is that using a tool like
version-control your content provides a litany of benefits over
content stored as rows & columns inside a database.
The issue is that using markup often creates a technical-bar that must
be met in order to contribute to a site. You need to know HTML (or
something simpler like Markdown) in order to write new articles and
edit old ones. That's why most CMS' will
provide an editing interface regardless of how the content is stored
— and once you've got an interface and abstracted away the
markup, you may as well use a database for the benefits they can
As mentioned in my first post, I've always marvelled at Paul Stamatious's site and
particularly his photosets. The layout and design is incredibly varied
and nuanced with lots of small edge cases that make it look just right.
I've always wondered how complex his templates must be to allow for all
those variations. Turns out he actually authors his site in HTML rather
than Markdown so that he has the control over the layout that he
This leaves me in a quandry. I don't particularly want to be writing
HTML whenever I write a post, but it does genuinely seem to be the
favourable approach unless I want to build a complex editing
interface. This is something I'll need to explore in a future post.
The Open Rebuild Begins
08 June 2020
It seems that 2020 is the year of the open site rebuild. So far I've watched as Jonnie, Frank and now Nathan put their thought & work process out there for the world to see.
My site isn't more than a collection of a few blog posts these days, but I've had big plans for it since about 2018, at least according to my journals. I've wanted to post more of my photography, share smaller thoughts more often but also have a place for deep dives and series. Inspiration unashamedly taken from Paul's site.
These plans scared me. They are big and imposing, and I struggle to
find make time to even update my Twitter bio. An open, incremental rebuild seemed the perfect solution.
However, whilst I cut my teeth on design, I'm primarily a developer these days, so my public rebuild is going to be a bit different. I'll cover the (minimal) design decisions that I make, but this is going to be about the code that runs the site.
This site has been built 100 different ways at this point - all of them complete overkill considering it's needs. My personal site has always been a place for to experiment with new ideas and test new technologies. Given all this, you're probably anticipating that I start talking about the hot JS framework du-jour, but instead I'll stop you there.
Rapidly moving from designer to developer, I missed a lot on the way, most of which could be considered fundamentals. I spent a whole week with only the most basic of CSS selectors before jumping into SASS frameworks (it wasn't Bootstap...what was the other big one?). I learnt JS whilst building a marketplace with MeteorJS & React (that was a wild ride). Using Meteor meant using Mongo, so I was very late to the SQL party!
I'll be doing my best to follow Jeremy's Resilient Web Design principles, using the native tools of the web to their fullest before cracking open anything more complex. I'll be server-side rendering everything, and I might even stick to using flat files. In short, I'll be coding like it's 1995!
This seems like an odd thing to do right? Well, as I said, I missed a lot of the fundamentals along the way. I learnt pretty much everything I know about development from reading blogs online, and the problem is that most blogs - particularly today - only talk about building with the hottest of hot tech. Those fundamentals just aren't sexy enough to get much screen time, but they are kinda... y'know... fundamental.
That's why I want to build this site in the open, always taking the simplest, most resilient and durable path I can; documenting it all the way with articles, guides and source code. I'll examine my options and explain my decisions as I go. I learnt so much from the open web: it's time I gave something back.
I'm going to be doing this around regular work and looking after an 18 month-old that's just starting to learn his own mind (no easy feat itself) so I can't say how long this will take, or when the next post will go up. I'll try to find a rhythm and make regular updates, but bear with me whilst I find my feet again. It's been a while since shipping anything!
You'll find the git repo with all the source below, along with a link to my (now) old site. In time I'll move the old content over too.
That's all for now!