Stupid Safari

This is a strange CSS bug in safari I found today: you can’t use animated gifs as CSS background images.

View this page in Safari, then try it in any other browser. I can only get the first frame to display in safari.

Stupid CSS

I’ve been wrestling with CSS bugs over the past three days while trying to hone a design, but the strangest one was finding out that two popular image replacement techniques (1, 2) don’t work in mac IE 5 if you use anything besides a heading element to hide your text.

So:

<h1 id=”logo”>logo text</h1>

will hide the “logo text” and replace with an image, but:

<div id=”logo”>logo text</div>

will not. Makes no sense and prevents me from using it on a public site, since I no longer want to use headers to describe logos.

Try this test page in Mac IE 5 to see the bug.

update: yeah! a fix!

Dangerous spam

I just got a new spam scam that looked exactly like this except with newer dates. It’s no doubt a Nigerian 419 scam, where you can only “collect the money” once you give them all your bank account info so they can empty it.

Still, the email is much more convincing than trying to help out the estranged son of Prince Mobutu get his oil money out of hock. I wonder how many people fall for this free money lottery scam.

Roadmap for future wikis

Yep, wikis are a total nightmare. I don’t know why I went easy on them in my previous posts, as I wanted to share all the things they do poorly when I posted recaps. Might as well do it now.

Overall, people that have had their “light bulb” moment with a wiki love them and would love to see wiki functionality in other kinds of sites. The following suggestions are all geared towards making wikis more easily understood and used by most web authors and readers by reducing the wiki cruft and wiki geek features to act more like a typical website people are accustomed to reading and building.

My first problem was finding any package that could output good html. Only a handful (maybe 3-4) could pass the HTML validator for anything beyond HTML 4.01, but all but one still output terrible markup. They either use line breaks instead of paragraph elements, or they forget to use closing paragraphs. Some packages (it looks like MoinMoin is one of them) output html in CAPS so you’ll never get xhtml out of them without doing modifications.

I don’t know why this is so difficult for wiki package authors to get, but if you want to build a powerful package, have it output pages that look like this:


<h1>Page Title</h1>

<p>first bit of text.</p>

<p>next bit</p>

PHPwiki was the only package I found that could do this.

Navigation is always going to be difficult, as wikis are supposed to be flexible enough to grow in any direction. Consequently, this means you often see a link to absolutely everything on the main home page, which is an information nightmare. It’d be nice if you could flag a handful of pages as the major ones, and have navigation bars build up automatically (on my wiki I had to hard code them by hand). Of course before you can have a nice nav bar, you have to dump the ones that ship with wikis, which leads me to:

Wiki package authors need to get over their geeky features. Just because you can do backlink searches, subscribe to pages, and measure file differences on all the previous versions of a page doesn’t mean you should display these things for all users. Look at this random page from a MoinMoin-powered wiki. How much actual content is there and how much is geek cruft that only a subset of users would care about or even know how to use? Give all but logged in users a minimum set of functionality that actually improves their experience, not hinders, and stuff the info in the footer, not the header of the site. I know wikis were designed by engineers, for other engineers, but the general public is beaking into the wiki world and not all of them know what CVS is.

As Barry found out, the template systems are fairly arcane, requiring you to modify html around programmic code (perl, php, python, etc, it’s usually intermingled in the templates). Approach wiki templates like a powerful blogging system. Templates should be pure html, with calls to functions that include other bits of content and html. Make templates for all those other bits too, so that when you include [$navbar$], you can also modify the html within the navbar include. Also make the main CSS file a template that can be used to control the layout and design of the entire wiki. I know this might mean a wiki could have 20 different templates, but them’s the brakes, and people would prefer the flexibility and control over their look and feel. Like blogging engines, most users would start with the main template, and only the industrious few would go into every template to make sure every last line of code was valid and correct.

Blogging tools have done templates this way since 1999, and so far I haven’t seen a single wiki adopt this method, though I’ve only looked at 7 or 8 packages and I know there are dozens now. It’s simply a matter of removing as much hard-coded HTML from within the wiki’s codebase, and move it out to your template engine. You don’t want people to get to the point of saying “boy I hate the way the calendar’s HTML is coded by my wiki package and I can’t modify any of it.” Let page designers sculpt and mold any and all HTML output by your engine, because this is how organizations work. A group has a site, they might have an engineer coding it, and a page designer making it look nice, while others work on content and marketing. Wikis should allow this type of backend collaboration as well as the frontend.

They also need to provide a method for linking beyond CamelCase. Give me a shortcut to make a regular, single word into a new page. Perhaps I could write &&contact and have that become contact?, and build a new page that doesn’t have to be called ContactThisSite in the URL and title in order to be easily added to the site.

I’m sure I’m missing a lot of things I found out while setting up my wiki, but this would be a good start to building the ultimate wiki package that users and designers would like.

Hard Knocked Life

I can’t say I’m 100% positive it’s all true stories, but the posts over at Gang Stories are absolutely riveting. I’m glad the author got out of that situation, and I hope he posts many more stories.

Although I’m just another boring kid that grew up in an all-white suburbia, at different times of my life I had some fucked up friends that liked to break shit, start fights, and basically cause havoc for no other reason than boredom. To this day I can’t watch the movie Kids, since the characters remind me too much of people I hung out with from time to time. Though my own teenage stories are way, way tamer, I still can’t believe some of the stupid destructive shit I did when I was 16.

Of course at my age and moving into my first house, it’s only a matter of time before I’ll be saying things like “goddammed, good-fer-nuthin teenagers broke my mailbox! Get off my lawn you punk kids!” Ah, just another part of life’s cruel comedy.

Behind the Wiki

Several people asked if I could upload my phpwiki changes for review, so here it is: 666kb zip

Keep in mind the following:

– If you want to use my code, install phpwiki 1.3.3 first, not 1.3.4. Then either copy my phpwiki-1.3.3 files over yours or do a diff on them to compare. I changed a lot of little things in all sorts of places I have forgotten.

– I hard-coded a few things like the nav in the upper left in various .tmpl files found in the /phpwiki-1.3.3/themes/default/templates directory, so change accordingly to match your site.

– I included my .htaccess files so you can see how I’m redirecting people at the root of my site over to /matt and how I got the /matt/HomePage wiki default document to switch to /matt/home (I changed the title of the default page in MySQL, but you could create a page called “home” instead).

– I’m providing it as-is to other wiki hackers so don’t email me with problems, as I can’t offer much help. My changes worked for me, hopefully they work for you or you can adjust accordingly.