# djtaylor.me

Insert tagline here

## Obligatory "new website" post

Pub. 2020 Jun 18

Last week I redid my website. I've been neglecting it for a couple years now and I want to stop. So this is about what this new one is all about and what I want to do.

### Desires

I want to start writing more.

I tried a thing several years ago where every week I tried to write about what I had worked on throughout that week. I kept this up for about 3 or 4 months or so, but none of those posts appear on this site. My amount of actual progress per hour back then was very low so I didn't always have much to talk about. In addition the focus was more about recording what I had done and less about getting better at the act of writing and explaining myself. The things I talked about were never inquisitive and never tried to be introspective or insightful. I feel like most of those posts were just collections of words.

In the past couple years I've tried to turn it around. Instead of "multitasking" while I'm programming I've started to take the time spent doing my personal projects more seriously. When I think about what it will take to level-up as a programmer, two things come to mind: learning to constantly think seriously about what I'm typing as I type it, and learning all of the various psychological things that influence whether I'm actually typing code or trying to do anything else. Both of these things just require practice. As a compliment to practice though, writing is a good way to stimulate that first one.

However, in the past whenever I've tried to write I always end up taking a full week to complete a post. The process of writing, rewriting, checking things as I'm writing them, realizing something as I'm writing and then going back and writing it all again, etc just takes a long time. There's also the problem that, as someone who doesn't have a job history doing the things that I really want to be doing, a lot of emphasis is placed on the front page posts on my website. They're supposed to be reflective of me. I haven't written anything in a couple years partly because of that. What I want is a place where I can write that's out of the way of the front page and where my writing can be what I make of it: sometimes rushed thoughts, sometimes unrehearsed and unproven ideas, whatever.

I guess that's just a long-winded way of saying that I added a new item to the site's navbar.

Going in, though, I wanted to redo the site. In the past couple years I've stumbled across a handful of sites that used my exact Hugo theme, and I think that's embarrassing. So I wanted to write my own site basically from scratch.

I've been down that road before though. My history of personal websites is as follows:

• In jr high my website was hosted on webs.com. Remember that site? It was all completely handwritten HTML. I think there were javascript animated snowflakes that fell constantly.
• In high school I played around with websites that overuse XmlHttpRequest to load content and format it. Even then I was over handwritten HTML, but was still stuck in the dynamically loading website phase. I'm sure high school me would have loved React and friends.
• In college I finally got a domain name and set up Github Pages (which I still use). The first site was using the Jekyll static site generator. That was okay for a while, but if I'm going to be switching back and forth between multiple machines (including a Windows one), I don't want to be installing Ruby all over.
• Next up was Hugo static generator. Hugo was actually really really nice. A single binary that you can just download, works pretty much out of the box. The main issues are with the math formatting and the templates. If you want to typeset math using mathjax, you can't use the default markdown formatter, you have to use the mmark formatter (at least in the versions I was using) which seemed to require random amounts of newlines in multiline equations. In addition, Hugo templates are crazy town and I didn't want to have to learn how to do the gymnastics required to go from a website in my head to a Hugo template.

This leaves us at my current site. The static site generator I wrote takes in almost-markdown and spits out almost-what-I-want. I figure every computer I ever use to work on my site will have a C compiler on it, so the generator is written in C. It now lives in a single C file that clocks a staggering 500 lines (gasp!) and is so much more easily modifiable than the Hugo setup. I'm happy with it.

Writing my own generator means that I have full control over the output HTML. This means that I get to do that thing where I focus on stupid things that probably don't actually matter. The one I got into my head this time around is that I want very minimal javascript playing with the content of the site. As much pure HTML and CSS as I can manage. I had recently read through a good bit of the CSS spec recently so I figured that with all this newfound knowledge I'd be able to make the site look how I want it without having to feel like I was randomly trying things.

For math typesetting, I chose to go with MathJax. I'm fine with this since it's reasonably small enough to check entirely into my repo, and the alternative (using a png latex renderer) ends up having blurriness and mobile issues whenever I've seen it. Plus a page with lots of equations will request tons of images which isn't ideal.

This isn't a major thing, but I don't like the whole "semantic web." Specifically, I don't like the whole <header>, <footer>, <article> kind of tagging for the same reason that I don't like doing things like typedef int64_t time_diff_t; in C. It hides the fact that time_diff_t is 64bit (as opposed to 32bit, etc) which is an annoying thing to keep having to refer back to if I forget, and I find it hard to keep up my programming speed while also having to pause for a second and think things like "should this return a time_diff_t or a int64_t? This function returns a int64_t and I need a time_diff_t out of it, should I cast just for clarity?" over and over. I also don't like functions that don't do anything. Like how some codebases have the concept of a "system unit" that could conceivably be any unit but is actually always meters, and then provide a double su_2_meters(double val) { return val }. Again, you end up wasting time looking to make sure you put all the correct noop functions in the code, and at the end of the day it has the same problem (but has it arguably worse) as inaccurate comments. The semantic tags are similar. Are they block or inline? Can't tell from just their name, I guess you just have to memorize it. Should I be using <article> here, or <section>? Or maybe <main>? Hm....

One of the things I'm inconsistent about is whether I feel like platform defaults should be respected or not. The only real answer to the question I guess is "only if it's easier to do so," but that's the problem isn't it? I'd wager that just about 0 programs that run on windows respect high-contrast mode. There's an interaction that happens between a platform that makes basic things (like making programs that conform to platform standards) complicated and the programmers who rebel and roll their own. I'll happily roll my own text boxes in native Win32 programs over using platform defaults at the expense of all of the accessibility features, purely because of how difficult it is to work with. However I think that downloading whatever google fonts every time you load a website is a bit much. The web is it's own kind of nutty: not only are the defaults all hard to read in paragraph form, but there are stupid amounts of things to keep in mind (I recently learned about prefers-color-scheme!). I've decided for this website I want to try to keep most things default as much as I can just because I don't have an extremely strong opinion one way or the either, but even that's probably the wrong choice.

### Actions

So with all that in place, I sat down Friday afternoon and in 2 hours had the pages from my previous site mostly generating right. Basic site layout, navbar, MathJax, generating the post lists, etc. Another 3 hours and almost all of the layout and new content was done, RSS feed was being generated, etc. At this point I'm feeling good: I've been making steady progress and it looks like I should be done in another hour or so just to do some touching up.

Now I didn't know this at the time, but apparently mobile browsers can mess with your formatting. In an effort to try to make non-mobile friendly sites readable, it will artificially shrink your page and sometimes increase font sizes. The way this happens is, from what I can tell, complete heuristics. In addition, while both Chrome nor Firefox had pretty accurate renderings of what the page would look like on mobile, neither of them gave any indication of why my text was bigger in some places than others. The area that normally tells you where its sizing parameters came from were completely mum on why the text was 26 pixels large when there's 2 things in the navbar, but 12px when there's 3. As a lot of these types of stories end, I lucked across a Mozilla reference page that explains it. So that was fun. Apparently the only way to disable this is to add one non-standard meta tag to your head, and then 3 vendor-specific css tags to your body. Maybe this is old news to front-end veterans, but I think this was a really stupid way to sink and hour or two.

I ran into a multi-hour long issues with images as well. I wanted images to have an optional caption at the bottom, since I've found that a lot of times alt-text is useful information to the reader when the image is loading correctly anyways. In addition to that, I wanted to be able to easily show 2 images side by side horizontally.

 What I have now What I want

As far as I can tell I can't actually get the text under the images to line up. As in, I don't think it's possible without javascript. It's certainly not possible with the standard box model because the text being not a subitem of the image tags means that there's no way to pass the image's width to the text span. The outside div can't be made to have a width the same as the first image item because even if were to remove the span from the sizing with a float: absolute we wouldn't include it in the hight calculation and there'd be no room for the text anymore. Admittedly flexbox is more powerful with it's multi-pass thing, but I'd be surprised if this was possible with flexbox.

There's also the issue that side-by-side images' captions don't line up on the same y-value. This is another one that can't be fixed with the box model: the layout info can't be shared between the 2 divs. This one (hilariously) seems more possible with some table or CSS grid magic, but I haven't figured it out.

After I had written my first post to the new "thoughts" section, I learned to my disappointment that the default font settings are just really hard on the eyes when writing longer paragraphs. After switching to the default sans-serif font it was still hard to read and I had to increase the spacing between the lines. Not happy about that.

### Reflections

I think it's disappointing that I spent so long trying to figure out why text looked shit on mobile and how I could possibly get 2 bits of text to line up at the same baseline. That latter one should have been 1 line of code, but instead I had to walk away in defeat. I wonder when it was that the people at the W3C realized that hierarchies are a poor standin for logic, and why they just kept going with it anyways. The number-one way of getting me to hate your library/platform/whatever is making progress more stop-and-go than absolutely necessary. Going from a rate of 1/3rd of an entire website an hour to 1 layout issue every 2 hours feels horrible. Having to re-read specs, trying to backsolve the layout-tree -> ui position and sizes, all to try to do something that's would be trivial to specify in a sane language feels horrible.

The site is pretty lightweight as it is, but on some of the more image-heavy pages Google PageSpeed says that I should be lazy-loading images. I find it funny that something that's considered a critical part of making a website mobile-friendly is adding more DOM-manipulating javascript everywhere. That's some good stuff.

After pushing through the negative bits, though, I'm glad I did this. I think.

Written by Daniel Taylor.
Email: culdevu@gmail.com

© 2020 by Daniel Taylor