<<  Page 14 of 14

Setting text width in HTML

This blog quite intentionally has very little formatting. “Quite intentionally”, because not only does it save my effort, but also lets mobile devices with tiny screens format the text the way they want, without having to fight my formatting. But there’s one piece of formatting code I use: limiting the width of the text column. That is a principle of typesetting that I disliked at first, but eventually accepted: long lines are just too hard to read; the eye too easily loses its place when scanning back to the left to get to the start of the next line.

Though a lot of sites limit text width, usually, from what I’ve seen, it’s done badly:

  • Specifying text width in terms of pixels. This produces annoying results for people with bad eyesight who use huge fonts, and for people who have portable devices with lots of microscopic pixels (such as what Apple calls a “retina display”), and who thus also use huge fonts (that is, huge when measured in pixels). It also can fail for people who have displays narrower than the specified number of pixels, since they can end up with lines that go off the edge of the screen, and need to keep scrolling the screen back and forth for each line that they read.

  • Specifying text width as a proportion of the screen width. This won’t overflow the screen, but may produce columns with annoyingly many or annoyingly few characters.

The best way to specify text width is relative to the font size. HTML provides the “em” unit, which is the width of the character “m”. About 35 of those translates into about 75 characters of average text, which is what Lamport’s LaTeX manual says is the maximum width one should ever use. (Personally, being an exceptionally fast reader, I don’t mind twice that width; but this blog is for other people to read, not for me. And above twice that width, even I start to get annoyed.)

One can set the width using HTML tables to divide up the screen into columns whose width is specified in “em” units; and there’s not too much wrong with that. But a width specified that way might be too large for smaller screens. Fortunately the CSS standard provides a way to set an upper bound on the width, without using tables:

<style type="text/css">
    .foo { max-width:35em }

The above goes in the “head” section of the HTML file. To use that style, one then writes:

<div class="foo">
    Text whose width is to be limited goes here.

It’s simple, and precisely what is needed: it produces a column 35em wide, unless the screen is narrower than that, in which case the column fits the screen. The “class” attribute can also be set for other HTML elements, such as <body> or <p>, so one doesn’t need to add extra <div>s if one doesn’t want to.

Blogging software

The weblog software that people seem to choose by default these days is Wordpress. Wordpress has a lot of features, is widely used and liked, and is offered as a free single-click install by a lot of web hosting providers. But several of the Wordpress blogs I follow have been hacked at some point. When I looked into blogging software, the reason became clear: Wordpress is a large piece of software, written in PHP, a language which originally was designed arose in a world where security concerns were much less significant, and which has addressed those security concerns (and other evolving needs) by adding things, not by a fundamental redesign. (UPDATE: it appears I was being far too generous to PHP in saying that it had been ‘designed’.) The result is a rather large, complicated language, which is hard to learn well enough to master all the security issues. Also, Wordpress uses an SQL database to store weblog entries, comments, and such, which opens up possibilities of SQL injection attacks. The single-click install is easy, but upgrading is not so easy; and if one runs the software for any length of time, one has to upgrade much more often than one has to install.

A lot of other blogging software, too, uses SQL databases to store weblog data. But databases add complexity; for one thing, to back up a database-driven weblog means issuing special commands to back up the database, in addition to doing the normal backup of the weblog’s files. The added complexity might be worthwhile if there were any real need for a database, but there normally are few enough weblog entries that using a file for each one is quite practical; and once written, they seldom change.

I suspect that the reason why blog software commonly uses databases is that PHP makes using SQL easy, and doesn’t make other ways of storing data as easy. In any case, it’s quite inefficient: even though weblog pages hardly ever change, the PHP/SQL combination means that each time a user asks to view a web page, a PHP process gets started up (or woken up), sends queries to an SQL server, receives the results, and rebuilds the web page using them, adding the headers, sidebar, and other formatting that the user has chosen. The sidebars often take further SQL queries. Due to this inefficiency, database-driven blogs are routinely brought to their knees when they draw huge traffic (as in “slashdotting” or “instalanche”). Right when a weblog is getting the most attention is exactly the wrong time for it to fail. There are various optimizations that can improve this — for one thing, PHP can be left running (WSGI) run inside Apache (mod_php) rather than re-started for every request (CGI); and there are also plugins which cache the resulting web pages rather than rebuilding them every time. But installing and maintaining one of those plugins is additional work; and even they don’t bring the efficiency up to the level that static web pages naturally have.

Of course you can easily move a Wordpress blog to wordpress.com, and let them handle issues like caching and keeping the software up to date. That’s how they make their money: by selling advertising on the blogs they host, and/or charging those blogs for premium features. The blogging software they give away is not a revenue source; indeed, if they were to make it too easy to maintain, they’d be sabotaging their revenue source.

I don’t grudge them their revenue — the people who write blogging software do need to eat — but personally, I feel like going to the other extreme. Thus this blog is done in PyBlosxom, a small file-based blogging package written in Python, which I’m using in static-rendering mode, where rather than being run each time someone visits, it is run once and generates all the web pages for the entire blog. PyBlosxom’s default mode has the author writing blog entries in HTML; I’m using a plugin that provides for writing them in Markdown.


There are a number of things which I’ve accumulated, as being good to write, but which I either haven’t written or have written for a very limited audience. They cover a wide variety of topics, and range in scope from technical details to the largest of questions. Here they come…

<<  Page 14 of 14