Building This Blog
How I did it
I’m building this blog the same way I tend to build most things lately: start with layout, then slowly add features once the shape feels right.
This post is basically a snapshot of what we’ve put together so far.
Starting with the bones
The first decision was intentionally boring: a page with a header, a main content area, and a footer.
Each of those sections is full-width, but the stuff inside is constrained to a centered wrapper that caps out at 1400px. That gives the site a consistent “frame” while still leaving room for full-bleed elements later.
Planning for full-width dividers early
I know I want dividers between sections (header → content, content → footer), possibly as SVG shapes.
So the layout is set up so that dividers can live between sections and go full width, without affecting the centered wrapper inside each section. That’s the big win: content stays constrained, dividers stay dramatic.
Before doing any real SVG work, we tested the idea with a plain solid-color divider. It’s a great reality check for spacing and visual weight without getting distracted by artwork.
Sticky footer (not fixed)
I wanted the footer to sit at the bottom of the viewport when the page is short, but scroll naturally when the page is long.
So it’s a “sticky footer” pattern: the overall layout fills the screen height, the main content expands to take extra space, and the footer ends up at the bottom when there isn’t much content. No fixed positioning, no weird overlaps.
Article layout: title first, then reading block + TOC
For the article page, the layout goal is:
- A full-width title area (still within the 1400px wrapper)
- Under that, the article text on the left with a max width of 720px
- Immediately to the right of the text block, a table of contents sidebar
- Any leftover horizontal space sits on the far right (unused)
The “butted up” part matters: the TOC isn’t pinned to the far edge of the page; it lives right next to the reading column, like a companion.
The TOC follows the viewport
Yes—what you’re describing is “sticky.”
The TOC is positioned so it stays visible as you scroll, but only within the boundaries of the article section. That’s exactly what sticky positioning is for, and it feels perfect for long posts.
When the screen is narrow, hide the TOC
On smaller screens, I don’t want the TOC at all. Reading comes first, and clutter is the enemy.
So below a certain breakpoint the TOC simply doesn’t render visually. No collapsing menu yet. If I want a mobile TOC later, I can add a button or an inline “On this page” section under the title, but for now: gone.
Colors: define them once, use them everywhere
I defined a small set of CSS variables for colors (text, muted text, main accent, and a few supporting accents). I’m using Tailwind v4, so the important part is mapping these variables into the theme layer.
Two takeaways:
- The names in
:rootcan be whatever I want. - The names in the Tailwind theme are what I end up using in classes.
Right now the footer background is the dark accent (accent-3), which gives the page a solid “base” and makes the content area feel lighter by contrast.
Content: Markdown files, rendered with MDX
Posts live as .mdx files in a content/posts folder.
I’m going with the approach where routes stay as normal Next.js pages, and MDX is treated as content. That keeps routing simple and makes it easier to evolve the content system later.
Once the MDX is being compiled and rendered, the next natural step is generating the TOC from headings—especially since heading IDs are already part of the plan.
What’s next
The layout is in a good place, which is exactly the point.
Next steps will probably be:
- generating the TOC from headings automatically
- dialing in typography for long-form reading
- swapping the solid divider for a real SVG divider
- maybe dark mode once the visuals settle
But the foundation is there: a clean frame, a readable article column, a TOC that stays out of the way, and a content pipeline that won’t paint me into a corner.