New theme for old blog

A while back, well after I’d purchased the current theme for this blog, I ran across another great responsive theme on someone else’s blog (unfortunately I never made a note of whose it was, so can’t credit them). The theme is called Selfy and I’d have to say it’s pretty clean and simple.

So I bought it in order that I could change the admittedly awful self-designed theme on my old blog. I’m no designer is all I will say. OK, fine, the old theme was rank, and I don’t want to talk about it. Really. Thanks.

Unlike the blog you are reading, my old blog consists of static pages. They are not generated at run-time by some server CMS with PHP or ASP.NET, instead the HTML files are generated by a client app on my laptop and then uploaded via FTP to the web server.

The app I used for this is called CityDesk from Fog Creek Software. It is so old that Fog Creek no longer (a) sell it or (b) support it or (c) even talk about it (that link for CityDesk in fact goes to Wikipedia). It was written in the days of Windows XP, and even to get it to work on Vista, you had to go through some hoops. Installing and getting it to run on Windows 10 Anniversary Edition yesterday was a bit of a laugh.

[Aside: if you want to use CityDesk on Windows 10 and have the install program for it, here’s the process:

• Run the install program to install CityDesk.
• If you try and run CityDesk immediately, you’ll get an error, something about srcvw32.dll. So don’t.
• Run CityDesk the first time as Administrator. This will solve the aforementioned problem.
• However, you’ll get another error about the DHTMLEdit ActiveX control being missing. This was provided back in the Windows XP days by Internet Explorer. Ha! Me installing IE? Yeah, not.
• Turns out the Microsoft made it available separately for Vista and the install still works in Windows 10.
• So download and install the DHTML Editing Control.
• Now run CityDesk.]

At this point, the real hard work was in front of me: making the minor changes to the articles in my CityDesk database so that they would support the new theme. It was especially so with regard to the images in my content: I’d used a bunch of different ways to float them left, right, and have them as part of the text flow (Selfy assumes that it can just expand images to the full width of the content – not in my case). Anyway, after a good six hours’ work tweaking the new CSS, comparing the content in the new look to the old content—and admittedly rereading some of the posts – it’s done. It’s here in all its Selfy glory: secondboyet.com.

If that were all that happened, this would be a short post indeed. However, I ran into a very weird bug in doing so.

I had many posts that had some markup similar to this:

<p>
    <img alt="Inserting p as red root" src="../Images/RedBlack/InsertSteps/Step0.jpg" />
</p>

Nothing too alarming, a paragraph holding an image element with an alt attribute for the description and the required src attribute for the url to the image itself. Basic stuff. This was the result, however:

Where was the image itself? Quick panic, but the image was definitely present in the Images folder. Must be something else then. So I started the Developer Tools to take a look at what it thought the HTML was. And this is what it showed me:

<p>
    <img &nbsp;src="../Images/RedBlack/InsertSteps/Step0.jpg" alt="Inserting p as red root">
</p>

Where the heck had that non-breaking space come from? Time for some Googling, but I found nothing (this seemed similar, but possibly was due to something else). In my clutching at straws, I even viewed the static page in a hex viewer: after all I was using an eight-year old program to generate HTML through an even older ActiveX DHTML editor. Who knows what it might be doing, right?

After lunch, I calmed down a bit. I’d already noticed that if I replaced the <p> tags with <figure> tags, the problem went away, so maybe there was something else going on. Now, as part of my acceptance of the Selfy theme, I’d just copied the JavaScript files over as well: maybe there was something in there. I commented them all out: the problem went away. I started adding them back in until the culprit was revealed: jQuery widowfix. To quote the description: “Widow Fix is a jQuery plugin to fix widows, or orphans, or whatever you call them—those single words on their own line. It does this by adding a non-breaking space in between the last 2 words.”

Not only that, it turns out that others have found out about the problem. Not only that, but there’s no fix, the developer acknowledges the issue, but has no idea how to fix it. In my case, the code was breaking apart the content of the paragraph tag, seeing the bit that starts “src=” as the last word of that paragraph and then changing the space in front of it to a non-breaking space. Which then breaks the browser render.

Solution for me? It’s my old blog, I don’t care that much about orphans when displaying those posts. The widowfix code is gone.

  Loading links to posts on similar topics...