Dusting off my blog. I have some custom templates and theme work in place now, but that was all done against a VERY EARLY version of zola (before it was even called zola).

My plan is to start a fresh zola project (default templates) and build a theme from scratch w/ tailwind.

I think I'm going to start by resetting the custom work I did to the theme in the first place. I like the overall structure, I just need to get rid of all the extra template logic I added for things like draft filtering. Zola knows how to do this on its own now iirc.

Lol. Actually it looks as if almost all of my original mods will have to stand until I rewrite the templates from the ground up. I suppose it doesn't really matter too much.
There just aren't blocks in places I can use to minimally override things in a meaningful way as-is.

I wish there was a way to pass config info to zola on the cli to override things in the toml file OR OTHERWISE have some template var set for when you're using `zola serve` rather than building. I've got a script tag in there for google analytics and I don't want it when I draft.

I suppose I can check the hostname in the script tag itself and branch that way.

Silly, but it'll save me from having to do what I had been doing (keeping 2 config files that are identical except for the tracker code in the prod one).
Probably best to not overthink this.

Not having any fun or enjoyment from this so far.

Okay, the chore is over. I have re-upped the hyde theme to the most current version.

Styles and other markup changes to follow.

Today I'm giving some attention to the theme reboot and I'm actually glowing because a way I'm learning about tailwind blog layouts is by viewing source on the tailwind blog.

Took some screenshots of the hyde theme for before/after comparisons. This is the "before". The responsive layout aspect is something I could afford to spend a little time on, huh?

I find myself second guessing myself on how best to build my tailwind styles.

Of all the options mentioned in the introductory text, I hoped to use postcss without a bundler or anything else, but I'm not sure if that means I'm supposed to use postcss-cli or if tailwind uses the postcss.config.js itself or what.

They talk about postcss-import (which I'd sort of prefer to the custom tailwind directive they have without) but don't explain how to install it/use it.

I'll settle for now and just use the tailwind custom stuff.

I've got a build working, with perhaps some small tweaks for pathing still to come.

Here's my starter.

h/t @webology for the guidance on minimal setups: https://gist.github.com/jefftriplett/ef9ae2cbca4abf6a74210c5881ea8254

What's nice about this (for me) is I can `env NODE_ENV=production npm run build` to get the treeshake happening. The size difference in output is dramatic.

This also opens the door to `npm run build -- --watch` to have postcss spit out updated versions of my styles on save

Yikes. Since I'm *that lazy* I added a dedicated `watch` script to the `package.json` do that thing for me.

Not really sure how best to handle the fact my main.css is a source file to generate a different main.css.

I'm leaning towards having a sibling to my `static/` dir for stylesheet sources so that this `static/` dir is my build destination. This is the dir that zola serves from.

Mmmm okay. I have gutted hyde's templates and removed all the old styles and so on. I'm hoping to retain certain aspects of the structure of the document since they hint at things zola does by default, but at this point here's how the site looks (lol).

I am still not sure how zola handles the code block syntax highlighting. There's a separate theme setting in the config for it. Let me set this in the theme itself (which is itself its own zola project - weird).

Ah, there it is. The output produced by zola has inline styles for the colors only, and I assume it relies on the rest of the styles not screwing up the whitespace handling for pre tags and so on.

Utility classes are happening.

A small struggle I'm having is figuring out when to extract sets of utilities via @`apply or just leaving them in the markup.

I'd really like to hide as much of the tailwind jargon as I can, but I think extracting some of this would make the layout more difficult to reason about

I suspect the way I'll rule on this is going to be reuse related. Like, if I have a particular text treatment for the dates on posts and the dates appear on both the list and detail pages, then I'd extract.

Turns out @`apply wasn't even working, so it looks like I have to do my classes all in the markup anyway for now.

Hmm. The docs mention you have to write your applied stuff in a particular way in the the stylesheet (which I didn't). Maybe that's where I went wrong. https://tailwindcss.com/docs/extracting-components#extracting-css-components-with-apply

Oooh, I see. It's breaking when I try to extract classes that use breakpoint specifiers like `sm:--` or `md:--`.

I think I can work around that.

The `post-title` classes can be split into 2 categories: stuff that is breakpoint conditional and stuff that isn't.

I extracted the stuff that isn't, but left the stuff that is in the markup. Seems okay.

I think I can probably leave this where it is for the initial text treatment. This is basically what the tailwind blog has (almost verbatim).

I can start to look at the non-article stuff like the sidebar (which I have on my actual site, not in this tester project) and list view.

Squish check

Yeah, I dunno. This actually seems fine. I just need to get the framing elements in there.

Trying to do one of those responsive deals where I make it a 2 col layout for wider viewports and stack for smaller but I don't get how this is meant to work.

I'm going to have to dial this back and run some experiments. Maybe I can use a codepen or fiddle to work this in isolation from my actual project.

I better break for dinner and come back to this later.

Got some work done after dinner. It's starting to come together.

I've got the "about" section sticky on the left, or pushed down to the bottom depending on the viewport size. I'm also tweaking the font sizes in there via breakpoints.

Getting closer to "done." I think my next thing is to turn my attention to the front page which is just a list of links to (my 3) posts.

I should be able to wrap this up tomorrow.

I have not made a single commit since I started this work.

Working the front page. I added markers to my articles so that Zola can auto-generate a summary for each post.

Also, this is (again) basically a hatchet job of the tailwind blog. I will be doing more customization after this initial pass for layout/structure.

I suppose it's a shame that all 3 of my posts were chained together as a series since this means each of the intro paragraphs mimic each other for continuity.

I suppose I can speak to the tailwindcss experience I've had up to this point.

For the most part, I'm still sort of "meh."
This definitely feels like it's closely related to my bootstrap experiences of "please just set nice defaults and I'll work some broad layout myself."

Granted, I've been picking the bones of already written layout/styles so far. Once everything is settled, I'll have room to explore a bit more.