This post is a bit rushed and written with nano directly on the server, as I am on vacation, but when Microsoft published Comic Chat as open source yesterday they also included an era appropriate version of Comic Sans. It's available directly in the repo, under commit f53e4b6, under "v1.0/shared/comic.ttf". I've taken the liberty of exercising my rights under the license, and have uploaded a copy, together with the LICENSE, so you can also get a copy even if they remove it. You can download it here. A quick legal disclaimer, so far, no statement has been made that this was done by accident, and Microsoft does own this font, so they can just release this. IANAL, but if they'd wish to claim this was an accident and that everyone should delete the files, they'd need to inform everyone - copyright law, or even contract law, does not require you to be a psychic, or second guess every license you accept, especially for something as low-value as a font from 1996. If Microsoft wishes to contact me, the link is at the bottom of the page.

Source code for the Microsoft Comic Chat IRC client - microsoft/comic-chat

Light and dark mode this time! Enjoy Baby Dusty peeking at you when browsing in light mode, even in IE6! ## How on earth did you pull this off? I learned some strategies as part of trying to make this nice looking on IE6. It helps that Microsoft still has some documentation on what's supported. and the Developer Toolbar is archived. While I obviously could've just used IE's weird conditional comments, that wouldn't help people trying to use other old browsers. **First off,** media queries. While the at-rule is supported since IE 5.5, an "and" rule with a query is always evaluated as false. Combine this with treating desktop as default, and it's reasonably fine. For example: body { margin: 0 auto 0 auto; // Fix the width at 770px to make sure the width is correct in IE6. width: 770px; @media screen and (min-width: 1px) { // Set a dynamic width on more modern browser where that's supported and important, like phones. max-width: 770px; width: 100%; } @media screen and (max-width: 770px) { // Remove the centering margins once we're below the 770px breakpoint. margin-left: 0; margin-right: 0; } } IE6 also doesn't support child combinators (the ones like `div > p`) just plain descendant selectors. Support for this was added in IE7, while media queries were added in IE9, so this can be used to apply rules specifically for that window. I don't have any such rules though. **Second,** you have to give up some of the newer semantic elements, like `<header>`, `<footer>`, and `<nav>`. IE6 doesn't properly nest elements under elements it's not aware of, the Developer Toolbar will show that they get parsed as separate opening and closing tags. This is most likely just a Trident quirk - IE was always famous for not parsing HTML like its peers. I replaced all of them with plain `<div>`s with styling based on IDs instead. Just remember to set a `role` attribute to not make people with screen readers hate you. **Third,** GIFs are surprisingly good. IE6 doesn't support transparent PNGs, and it turns out that lots of the art I have do 256-color, 1-bit alpha _really_ well. Other than that, not many changes were needed. I ripped out a lot of things like flexboxes back in the start of 2025 when I tried to make this site be usable in IE4, but that's for another post, involving Caddy powered crimes... * * * I'd like to mention that I am aware of some layout issues in IE6, specifically to do with images in posts, and the artwork page. Those aren't that trivial to fix, sadly.

Light and dark mode this time! Enjoy Baby Dusty peeking at you when browsing in light mode, even in IE6! ## How on earth did you pull this off? I learned some strategies as part of trying to make this nice looking on IE6. It helps that Microsoft still has some documentation on what's supported. and the Developer Toolbar is archived. While I obviously could've just used IE's weird conditional comments, that wouldn't help people trying to use other old browsers. **First off,** media queries. While the at-rule is supported since IE 5.5, an "and" rule with a query is always evaluated as false. Combine this with treating desktop as default, and it's reasonably fine. For example: body { margin: 0 auto 0 auto; // Fix the width at 770px to make sure the width is correct in IE6. width: 770px; @media screen and (min-width: 1px) { // Set a dynamic width on more modern browser where that's supported and important, like phones. max-width: 770px; width: 100%; } @media screen and (max-width: 770px) { // Remove the centering margins once we're below the 770px breakpoint. margin-left: 0; margin-right: 0; } } IE6 also doesn't support child combinators (the ones like `div > p`) just plain descendant selectors. Support for this was added in IE7, while media queries were added in IE9, so this can be used to apply rules specifically for that window. I don't have any such rules though. **Second,** you have to give up some of the newer semantic elements, like `<header>`, `<footer>`, and `<nav>`. IE6 doesn't properly nest elements under elements it's not aware of, the Developer Toolbar will show that they get parsed as separate opening and closing tags. This is most likely just a Trident quirk - IE was always famous for not parsing HTML like its peers. I replaced all of them with plain `<div>`s with styling based on IDs instead. Just remember to set a `role` attribute to not make people with screen readers hate you. **Third,** GIFs are surprisingly good. IE6 doesn't support transparent PNGs, and it turns out that lots of the art I have do 256-color, 1-bit alpha _really_ well. Other than that, not many changes were needed. I ripped out a lot of things like flexboxes back in the start of 2025 when I tried to make this site be usable in IE4, but that's for another post, involving Caddy powered crimes... * * * I'd like to mention that I am aware of some layout issues in IE6, specifically to do with images in posts, and the artwork page. Those aren't that trivial to fix, sadly.

The answer is probably no, but I still feel the yearning for it. Or maybe it's time to ditch the idea completely? It's not a massive secret that I don't blog here much. Some part of it is the design - this isn't super readable for a blog, and I've never been able to style text posts in a way that I like. Another part is just how complicated it is to make a post. ## Introducing Jekyll I use a static site generator, Jekyll, which isn't uncommon for nerds. How Jekyll works is fairly simple when it comes to blogs. All posts are Markdown files, stored under `_posts`. Each post has a "front matter" which sets properties on the post. For example, here is all of `_posts/2020-05-05-blag.md`: --- layout: post title: "Oh look, a blog" date: 2020-05-05 19:54:00 +0200 --- Thought this would be better than the old single page with an image. Need some place for longer technical stuff, I suppose. Go look at my Twitter instead. It's more exciting. Immediately you may notice that making a post is a bit more complicated than just making a file and going to town in Notepad. Bare minimum, your file needs that front matter, with the "post" layout and the title. That's in fact how drafts look like - as I'm writing this post, the front matter is: --- layout: post title: "Should I make another static site generator?" --- Drafts are stored in `_drafts` and are only accessible locally, when running Jekyll's internal web server. Now, you may have noticed that this means there's extra work when publishing an article too. You need to move and rename the file to include the date, and add the date to the front matter. Painful. I used to do all this manually, but eventually I wrote a shell script, `tool.sh`, which does this for me. Now I get to make posts with a simple `./tool.sh newpost "Should I make another static site generator?"` and publish them with a simple `./tool.sh publish "Should I make another static site generator?"`. After that all I need to do is a `git commit` and a `git push`, and the GitLab pipeline will deploy it to my site. At this point, I hope anyone who is using something more modern, like _Blogger circa 2004_ , are screaming and pulling their hair out over this workflow. To reiterate, to write a post I have to: 1. Start my computer. 2. Open Visual Studio Code. 3. Run a shell script to create a post. 4. Write the actual post. 5. Run the shell script again to publish the post. 6. Commit the published post. 7. Push it to the repository where GitLab will start a worker to build it into a website, and put it on my server. Can you guess why I'm not making any posts? After all, the best ideas come when you're half asleep, or on the shitter. I'm not bringing a computer with me on the shitter. ## Do I need Jekyll? Jekyll gives you a decent blog out of the box, with the Minima theme. Embed tags, site map, RSS, you got it. You may not believe it, _I'm still using Minima under the hood on this site,_ there's just a lot of overridden templates. However, over the years, I've ripped out more and more of the Jekyll plugins, and replaced them with templates. The sitemap plugin didn't account for changes to templates, but rather just the post itself, so `tool.sh` now pulls dates from the git history, puts it in a YAML file, and lets Jekyll handle filling in a sitemap.xml template. The "SEO" plugin generated lackluster embeds and metadata for the artwork section, so it was removed as well, and replaced with roughly 100 lines of template spaghetti. At this point Jekyll doesn't really bring much to the table, beyond being something that applies templates. In a way, this is the strength of Jekyll - it's very flexible, and could be used for all kinds of sites. It's how I can generate an artwork gallery. So, no, I don't really need Jekyll. Anything that can do templating and Markdown will work. ## Do I need it to be static in the first place? This is a more complicated question. The nice thing is that it's very "fire and forget" once built. It's much harder to compromise a pile of files on a dumb web server, compared to something with a login system and fully featured dashboard. However, you'll never get over everything having to have a separate "build and deploy" step when you're not serving directly from the source. That means you can never realistically use an app for writing posts, because it's unlikely you'll find a git server that supports MetaWeblog which is an extension of the Ancient Blogger API. The downside to leaving the static site generation world is that I'll need to move the blog to a different subdomain. My site stays usable down to IE6 without any JavaScript - I doubt that any modern fully featured blogging solution will do that, if it even lets me do things like an artwork gallery. ## Final thoughts Maybe the way forward is to have a separate blog, and just modify the main site by hand. Or maybe implement MetaWeblog as a daemon that can handle all the committing, renaming, and pushing for me. Regardless, if I want post more often, I probably need to change something. * * * I actually wrote a very basic and kinda bad static site generator back in 2013. Maybe I should revive it? :D Also, as a funny aside, I would've probably changed the name of this post if it wasn't painful to do so.