The bug is this: If you have a textarea with a width specified as a percentage (most commonly 100%), and there’s enough text in the textarea to cause it to scroll, the textarea will scroll up by a few lines for each character you type, only stopping when the line you’re editing reaches the bottom of the box (or the scrollbar reaches the uppermost position). Sometimes, when deleting text, it even scrolls up further than that, leaving your cursor somewhere outside the visible part of the textarea. Sounds fun, right?

Since the bug didn’t exist before IE8, it can be repaired by activating Compatibility View, which sends the page through the old IE7 engine instead. If you’re already doing the extra bit of work to accomodate IE7 users, this might not be a half-bad solution. But if you want to avoid regressing to an earlier version of IE and dealing with all the CSS hacks that implies, I recently found an alternate solution courtesy of the Simple Machines forum developers.

The bug is triggered when the CSS “width” property (and only that property) is set to a percentage. So how do you set width without setting “width”? By setting min-width and max-width to the same value! It looks a bit odd, but it’s perfectly standards-compliant and should be interpreted correctly by all major browsers. Do it like this:

textarea {
  width: 700px;
  min-width: 100%;
  max-width: 100%;
}

Note that the explicit non-percentage “width” value is required to avoid triggering the bug; it gets overridden by the other two properties anyway.

If you need to support IE6 (which I strongly recommend not doing unless human lives are on the line), you must keep in mind that it doesn’t understand min- and max-width, and will set the textarea to the fixed width you specify. If you’re not okay with that, you’ll want to feed a “width: 100%” declaration to IE6, probably using an alternate stylesheet linked via conditional comments.

Figuring that MediaWiki was probably overkill for this project, I struck out in search of something that would be easier to install and configure for me, and easier for non-technical users to maintain. What I found was DokuWiki, a somewhat minimalistic wiki platform that explicitly aims to fulfill the documentation needs of “developer teams, workgroups, and small companies.” Perfect!

As I soon discovered, one of DokuWiki’s distinguishing features is that it does not make use of a database for storage, as so many other wikis and content management systems do. This makes installation incredibly simple right off the bat: Just drop the files in a directory on your web server and go. All of your pages are stored as plain text files (e.g. another_wiki_page.txt)  in a directory hierarchy that matches the hierarchy of “namespaces” you create on the wiki. In this way, your content remains organized and perfectly readable even when you take the wiki software out of the equation.

For the most part, DokuWiki’s syntax is pleasant and sensical. Instead of MediaWiki’s odd multiple-single-quotes scheme, you have //slashes// for emphasis and **asterisks** for strong emphasis, which feels more intuitive. Instead of MediaWiki’s bizarre syntax differences between internal and external links, DokuWiki treats them all the same: [[link_target|Link Text]]. But then again, there are some strange and arbitrary syntax decisions on DokuWiki’s side, like the fact that the largest headings are surrounded by ======Six Equals Signs======, and the number of equals signs goes down by one for each sub-heading level. Weird, though I suppose it’s in the name of plain-text readability.

Uploading images and other files to DokuWiki is a breeze, thanks to a pop-up media manager that includes a multi-file Flash uploader and can insert wiki-links to your files with a click. Nifty media icons abound in DokuWiki’s output, with PDF files, Word documents, and more each getting their own instantly-recognizable icons. External links and email addresses also get unique icons, making them stand out nicely on the page. The “pretty by default” approach extends to text, which gets automatic curly quotes and various other typographic entities in much the same way that WordPress output does.

Given that I’m using DokuWiki for documentation on a company intranet, I would be remiss if I didn’t mention what an absolute cakewalk it is to integrate your own authentication scheme into it. If you already have a table of users in a database somewhere, as I did, you can set up DokuWiki to authenticate against it in the time it takes you to write a couple of SQL queries. There are other built-in authentication modules you can use, and if none of them meet your needs, writing your own is surprisingly easy (and well-documented) if you have a decent knowledge of PHP. There is also a fairly comprehensive ACL system that becomes much more useful if you set up your authentication scheme to provide “groups” to DokuWiki, or if you’re using the built-in mechanism.

One downside I’ve encountered in terms of usability is DokuWiki’s strict adherence to a particular naming convention for both page names and media file names: Only lowercase letters, periods, dashes, and underscores are permitted. The aesthetics of this decision leave something to be desired, especially since the name of the page you’re on is (at least in the default theme) displayed at the top in very large text, and probably:looks:ugly_as_sin. I’m not sure why capital letters and spaces are disallowed, since they are both quite safe to put in a filename. You can set an option to superficially replace the ugly page names with the contents of the first heading on the page in question, but this just makes the page’s “real name” harder to discover when you have to link to it, and the visual duplication of the page title and the first heading is far from nice-looking.

Thankfully, DokuWiki presents itself very well in all other aspects, and the overall package has so many good things going for it that I can’t help but give it my recommendation. If you want a lightweight, documentation-oriented wiki that feels almost as slick as WordPress but gives off a more techy vibe, DokuWiki can definitely take you there.

Unfortunately, after the upgrade, every other form submission on the backend was giving me blank pages and error messages, and I determined that my outdated theme was likely to blame. What’s more, I had foolishly made several customizations to the theme’s CSS, which of course would not be preserved when I upgraded it. Since I always thought that theme was a bit dull, anyway, I figured it would be as good a time as any to search around for a new one. As a side note, the new theme browser/installer in 2.8 made this task incredibly easier than it had been before.

So now we’re rolling along error-free with a new theme and all my customizations safely stashed in the Custom User CSS plugin. I’m still not totally satisfied with this theme (especially the weird fadey drop-down menus) and will probably change it again in the future, but that’s life. On the positive side, the main content area is now just wide enough to squeak a 640-pixel-wide image into.

One of the non-CSS customizations I had made to my old theme was to add several lines of PHP that would prevent my content from being “texturized” – straight quotes replaced with smart quotes, doubled hyphens replaced with real dashes, etc. When I enabled the new theme and the texturization returned, I was surprised to notice that the one thing about it that really annoyed me had apparently been fixed: Straight quotes inside <code> blocks are no longer converted into smart quotes. I’m not sure if this is a fix on the part of the theme or WordPress 2.8 (I don’t see anything in the changelog about it), but either way I’m happy enough to leave the feature turned on.

The one thing that really impressed me about 2.8 is the new syntax-highlighting, line-numbering, generally awesome-looking code editor. This is the first time I’ve seen anything like this, though in retrospect it seems like an obvious idea: If we can already do WYSIWYG editing for normal content, why not apply some nice formatting and colors to code-editing as well? If you’re curious to see what this looks like, the WordPress 2.8 release announcement has a slick video overview that touches on the code editor and various other new features (I recommend watching it, if only to witness the incredibly high production values for it being an announcement of a point release).

Many people see Twitter’s tagline “What are you doing?” and equate it to publishing every boring, mundane detail of what goes on in one’s everyday life, ala the infamous “Twitter shitter“ example. While I suppose one could use Twitter in this way, they surely wouldn’t retain many followers. The point of the whole thing, at least in my mind, is to tell all your friends about things you might mention in a normal face-to-face conversation; the old “What have you been up to?” line. If something is so mundane that you wouldn’t bother mentioning it or showing it to anyone in person, you’re probably not going to tweet about it either.

Beyond that, Twitter also serves as a unique mode of communication, a way of carrying on a conversation with someone. It’s close to the immediacy of instant messaging, but is much less intrusive, and every message is a broadcast to everyone who’s interested in what you’re doing. This makes Twitter particularly well-suited to casual queries not directed at any one person, though it can of course be used for more direct communications with the handy “@username” idiom. Some might find it strange that status updates and conversations are mingled together in the same timeline, but I find Twitter’s ultra-simplistic approach appealing (and there’s always Direct Messaging for private exchanges).

One might point out that all of Twitter’s features appear to be a strict subset of the communication tools that Facebook provides, and if you said that today, you’d be right. A year or two ago, it was a different story, but Facebook is always reworking or revamping something. Since Twitter appeared on the scene, Facebook added some new features that brought them up to parity, such as displaying wall posts in your timeline as “targeted” status updates (mimicking the @username thing). Right now, I only perceive two major differences between the ways that Facebook and Twitter approach social networking:

• Facebook is much more private and self-contained than Twitter. Unless you choose to lock down your timeline, everything you post to Twitter is out there on the internet, where absolutely anybody can read it (and maybe respond to it). On Facebook, typically only your friends or the people in your social group can see your status updates, and privacy is a much more fine-grained affair than Twitter’s boolean switch. This follows directly from the fact that…
• Facebook is a vastly more complex application than Twitter. Facebook isn’t even an application; it’s a platform. Where Twitter goes the ultra-simplistic route, Facebook’s design is multi-faceted, all-encompassing, and extensible. It’s not just status updates, it’s wall posts, photos, videos, groups, organizations, comments, discussion boards, polls, and just about every form of social interaction you could possibly think of (and probably a few more that you couldn’t think of).

It’s that last one that rather turned me off Facebook, and made me willing to check out Twitter. Facebook is so huge and complex that you can spend hours each day just wading through all the different channels for socialization, and while some people may enjoy doing exactly that, I always get the sense that I’m wasting a lot of time for very little gain. Twitter is social networking on easy mode; it has exactly the functionality you need to see what your friends are up to, and no more. I can appreciate that kind of focus and simplicity.

As a side note, I’m definitely not a fan of Twitter’s 140-character message limit, mostly because I frequently want to say things that are a good bit longer than that. I’m not sure exactly what Facebook’s limit on status updates is, but it seems much more reasonable by comparison. Might Twitter allow longer messages in the future, in a way that doesn’t require click-throughs and API tomfoolery? I hope so.

Also, since someone on Twitter suggested it, I slapped together a video of Twittjr in action, and reactivated my three-years-old YouTube account to upload it. Sorry for all the noise, it’s due to this room being heavily air-conditioned (it is adjacent to the CSH server room).