The Wiki Weekend Part 5: Finishing Touches, Conclusion

Page created: 2025-06-09
Updated: 2025-07-18
html warden icon

Back to HTML WARDen.

We’ve come to the last part of this "making of" series. I hope it’s been fun.

First, what’s with the name?

The name "HTML WARDen"

"What should I call this? Something HTML? HTML Something?"

I tried some project name generators. Those are always fun. I’ve even made a couple myself. Some of the results were funny, some were cool. As always, none were quite right, but that was what I expected. I never end up actually using anything from those name generators, but they get the brain on the right track.

At some point, I either saw or thought of the word "warden".

In genre fiction, I see "warden" used a lot in the sense of guardian. I like that.

What I pictured was a keeper of documents, kind of like a shepherd, in a forest of HTML. Herding and looking after the pages.

I’m not 100% how I ended up putting it together, but at some point I realized that there’s a "Ward" in "Warden" and that made me think of Ward Cunningham, the creator of the original Wiki! If you’ve never visited the C2 WikiWikiWeb, I highly recommend it. Especially for programming language geeks, there’s some great stuff in there:

I wonder if wikis would have been so popular if the original hadn’t been so good?

Even if it hadn’t, I firmly believe web developers would have been bound to keep inventing the concept anyway, much as nature keeps converging on crabs. (wikipedia.org)

The pixel art icon

I’m one of those devs who likes to have a "clean compile". In new projects, I treat every warning as an error.

And if you have a website with no "favicon", you’re going to have a warning in your console the whole time you’re working on it.

(History time: I remember when Internet Explorer 5 added the concept of the "favicon", so-named because it was used when you added a website to your favorites (bookmarks). It was a fun idea and I’m happy we have them, but it always gets my goat that ever since the year 1999, we’ve had to either put a favicon.ico file at the root of a website or endure a 404 error on the server side and, later, when Firebug showed the way, the browser dev tools console.)

Anyway, rather than put up with that warning, I got out the Wacom drawing tablet and fired up Krita and made myself a logo. I liked the idea of a "warden" as a mysterious (but also kinda cute) cloaked figure like something from an old LucasArts game.

screenshot of the warden icon being made in krita

And, wow, I had no idea Krita was so good for pixel art! It even has pixel art brushes (shown in the screenshot above). I drew the icon in about five minutes, tried it out for a while, and then came back tweaked it for another ten minutes. Krita rocks!

(By the way, the screenshot above is only 18.3Kb. How? By using a reduced indexed color palette in the PNG image.)

Anyway, that got rid of the warning.

The other cool thing was figuring out how to display the tiny 32x32 pixel icon as a larger graphic on the wiki (and these pages) without it becoming a blurry mess.

Here’s how: you style it with image-rendering:pixelated like so:

<img src="icon32x32.png" alt="HTML WARDen Icon"
  style="width:128px; height:128px; image-rendering:pixelated">

Another really cool thing browsers and styles can do.

The CSS

Quick rant: So apparently a debate is currently raging about whether or not web developers should be learning CSS? Like, I guess people are just learning JavaScript frameworks and skipping the basics entirely? That’s crazy-talk! Of course web developers should learn (at least a little) CSS. And I hope it goes without saying, HTML. It’s perfectly fine to specialize if you want. But you gotta know the foundations. The full CSS spec is huge and very difficult to master. But a little bit of CSS goes a long way!

Anyway, this is the entire style definition for normal pages in HTML WARDen:

body {
    margin: auto;
    padding: 20px;
    max-width: 800px;
    font-size: 1.2em;
    background: #FFE;
}

That’s not so bad, right?

Everything else in the stylesheet is for the split-pane editor (Part 2). And even with that, the entire thing is 76 lines.

Also, this stuff used to be waaaaaaay harder because we had to abuse mechanisms that were meant for documents, not user interfaces. (If you learn a little 'ROFF or TeX, the early CSS spec will suddenly make way more sense!) Flexbox alone has changed everything and I find myself referencing my own flexbox cheatsheet page all the time.

Static vs "live" wiki?

As mentioned in Part 1, there are other ideas floating around in my head along with that split-screen HTML editor featured in Part 2. They are:

One: Using a light Markdown-like syntax as an intermediate format for editing HTML in my editor of choice. (The document would start as HTML and end as HTML, but I would edit the compatible parts in a lightweight structured text format.) I’m not doing that as part of HTML WARDen.

Two: Always "save" pages as a complete HTML document so that the wiki is, at all times, also a complete static site. I’m not doing that either, but I thought about it.

(The rest of the wiki ideas exist in an amorphous soup-like state in my mind and my notebooks.)

In fact, by the second day, I was still thinking the wiki would be exported as static HTML for viewing.

But the problem I was running into was wanting to accommodate all of the growing number of combinations, including:

  • No logins, completely open for editing and all live

  • No logins, completely open for editing, but with static exports

  • Guest read-only live view, live edits with login

  • Guest read-only static view, live edits with login

  • Guest read-only live view, live edits with login

  • Completely locked down, requiring login to view

It’s certainly possible to support all of this, but the if/else logic in my save.php and head.php were really starting to get hairy.

I decided, once again, to embrace radical simplicity. I tore it all out.

A single use-case is currently supported: A "live" (rendered each time by sandwiching the body with a head and foot template), editable wiki for logged-in users.

I can always add other use-cases later.

Side quest: visualizing the repo

Writing about this project may actually end up taking longer than the software itself. (Update: It has.) It’s had diversions within diversions (see The Project Stack!), but it’s been fun.

This is a tiny piece of software, and it was made quickly, a wiki wiki.

I wanted some way of visualizing what such a small project "looks" like.

One way to "look" at the repo is by line count:

$ wc -l *.php templates/*.php
   34 core.php
  153 edit.php
   24 example_settings.php
   30 index.php
   94 link_creator.php
   20 login.php
   27 save.php
   28 settings.php
    7 templates/foot.php
   28 templates/head.php
  445 total

But I wanted something actually visual. A picture.

So I spent one morning making a little Ruby script to help with that.

And here’s the result for HTML WARDen (with plenty of manual adjustment in Inkscape):

rectangles with lines representing the files described above

In case it’s not clear, each line in the image is a "line" of source with the indenting and width determined by the characters in that line.

The image was generated like so:

$ shape.rb *.php templates/*.php > files.svg

Here’s the shape.rb script: SVG Sourcecode Shapes

(I initialy wanted to graphically compare HTML WARDen with MediaWiki. But it quickly became apparent that making an SVG graphic for MediaWiki without adding lots of features to my script would make my computer explode, and I don’t think it’s worth my time. So, for comparison, the entire HTML WARDen repo currently stands at 76Kb and MediaWiki is over 400Mb. It’s not fair or even sensible to compare the two, but it’s fun anyway.)

What can I say? I really, really like small programs.

Next

The next thing to do with this is start working on file uploads. I’m trying to decide how to handle media. I’m thinking it might work like the Link Creator where I have a floating "tool" with an uploader and an image gallery of already uploaded pictures to embed in the current page.

If I’m not careful, this thing might get over 100Kb!

Conclusion

I’m still pleasantly shocked at how quickly this came together. I did normal family stuff during the weekend too, so the total time spent on this was well under 16 hours. (The only thing I’ve added to the repo since then is the README.)

What I want people to take from this is a sense that you can do this stuff too!

The speed isn’t the point. The point is that you can make useful and fun things with a surprisingly small amount of modern browser standards, vanilla JavaScript, and simple, stable server-side technologies like PHP and plain old text files.

I learned how to make websites many years ago by doing "view source" on pages I liked. I typed the HTML by hand into notepad.exe. I had no idea what I was doing. But I could make things and put them up where my friends and everyone else online on planet Earth could see them. How cool is that?

You could say that a lot has changed since those early days.

But, you know what? You can still "view source" on web pages now. And you can paste the parts you like into a helloworld.html file and open it in your browser to see what it looks like. And how cool is that?

Have fun!

(Edit: You can now go beyond the weekend, starting with Death to WYSIWYG!)

Back to HTML WARDen.