Caveat Lector

The eminent Speaking Aardvark points out a right brilliant article on typography for the web, suitable for everyone.

Short on specific how-tos, but long on understandable explanations of why-tos.

The RSS Wars are still raging, but there’s a bright spot: the brand-new RSS Validator, noted on diveintomark and elsewhere. I’m going to talk a brief bit about what validation is, and then I’ll validate my own feeds and fix them right before your eyes.

(Movable Type users: note also Jonathon and Phil’s warning about your username in your RSS feed.)

RSS feeds are small XML files with information about the latest updates to a web page. They are consumed by news aggregators, which zip around to sites you’ve told them you like, grab their RSS files, and show you a nice layout telling you what’s gone on in the blogsphere while you were involved in lesser pursuits such as earning money or sleeping.

Now, an XML file can have things wrong with it in two distinct ways. The first way is to do something that violates the syntax rules of XML itself: e.g. not closing an element with an end-tag, or using a bare ampersand instead of its character-entity equivalent (&). (That last is illegal because ampersands are supposed to signal entities in XML. Bare ampersands confuse the computer, so they’re not allowed.)

The second way is to break rules governing a particular kind of XML file, such as an RSS file or an XHTML file or a DocBook file. The rules for different kinds of XML files are different, of course—RSS doesn’t look anything at all like XHTML! The point is, it’s possible to specify such rules, and if they’re properly specified it’s possible to ask a computer to check that a given document obeys them.

Totally nitpicky geeks will tell you that checking for XML syntax correctness is “parsing” and checking against a set of rules is “validation.” All you need to take away from that is that a good validator will do both for you.

If your blogging tool generates your RSS feed, you shouldn’t run into many XML syntax errors. The likeliest one is an unescaped ampersand in an URL, which you can reasonably ignore, as it doesn’t indicate a global problem with your feed. (By all means go fix it in your blog—I’m not advocating keeping known errors!—but it’s not overly important.)

So, moment-of-truth time; let’s check my feeds. I expect there will be some problems, as I haven’t touched my feeds since I moved CavLec, and both RSS and Movable Type have changed a bit since then.

First, the RSS 0.91/2.0 feed. Hm. Sure enough. Very clever of the validator to figure out I’m an old Movable Type user. Right, then: three problems, two of which are related. The first problem is that I haven’t put my email address in the <webMaster> element. Well, that’s easy enough to fix.

The second and third are a little trickier; I apparently have a problem with the date format. Since I don’t know what an RFC 822 date is supposed to look like, I shall have to click on the little help link to find out.

An RFC 822 date looks like this: Wed, 02 Oct 2002 13:00:00 GMT. The Movable Type code for this, unless I miss my guess utterly, is %a, %d %b %Y %k:%M:%S CDT. You’ll have to enter your own timezone at the end; Movable Type doesn’t have a tag for the appropriate timezone format. If you care about being an hour more-or-less off, you’ll also have to change that timezone in accordance with daylight-savings. Messy.

Also be careful if you blog in a language other than English; be sure to add language="en" to your <$MTDate$> template tag, so that the month and day-of-week abbreviations are correct. (What linguistic imperialists wrote RFC 822 anyway? Sheesh.) I have to do this myself, since my dates are Latin.

I could also ignore the last two paragraphs entirely and cheat by changing the <pubDate> tags to <dc:Date>, which uses the date format already in my template. I am stubborn, but not quite stubborn enough to resist this easy way out—especially since it appears that %d has a bug preventing it from padding single-digit dates correctly.

So, let’s try again. Woot! Feed validates.

Next the 1.0 feed. Same problems. Fixed. Try again. Woot.

Now, if you use Movable Type you don’t have to do these fixes by hand. Go ye and download corrected templates from the same kind people who wrote the validator. (Truth be told, it’s what I did after I ran the validator.) I just wanted to give you folks a quick idea of what validation is like and how to go about fixing validation errors.

If you use Movable Type and are having trouble with your feeds, feel free to ping this post. Otherwise, drop me a line.

AKMA took one look at Journeyman Renee’s page and said, “Wow. Want mine to look like that.”

So he’s tackling another markover. All by himself. He even told me to quit bloody well emailing him my longwinded explanations until he was sure he’d hit a snag he couldn’t resolve (only he said it much nicer than that, naturally).

How cool is that? Exactly what I’d hoped would happen. If you have any sort of an eye (which I don’t), web design and CSS are irresistible toys.

I showed Loren a trick the other day that I might as well share with the group. Even if, as he says, an MT plugin is probably a better way to do it.

Problem: Loren has several different poets he wants to write about and maintain category pages for. How can he get a listing on the front of his site of just the poet categories?

Movable Type allows category listings; you can see one in my sidebar. The MT tag in question is <$MTCategories$>, which you can read more about in the most excellent and readable MT documentation. The issue here is that there’s no way to pare down the category listings to just the categories Loren wants.

Not with MT alone, anyway. There’s a way to fake it using CSS.

The keys here are the MT <$CategoryLabel$> tag, the MT dirify attribute, and the CSS property display. The first of these, combined with the second, allows you to pop the category label into an HTML class attribute. You can then use the category label as a CSS selector to trigger either display: none or display: something else (block or inline, as appropriate).

Sounds jargon-y, but watch it work. Imagine that Loren has just created three poet categories, Tennyson, Yeats, and Garcilaso de la Vega. (I don’t know if Loren reads Garcilaso, but I need a multiple-part name for demo purposes, and I’m fond of Garcilaso.)

Now let’s create the template chunk. A category list is a list, so let’s use <ul> for it, and put each list item in a <li>.

<ul id="poetslist">
<MTCategories>
<li class="<$MTCategoryLabel dirify="1"$>">
<a href="<$MTCategoryArchiveLink$>"> <$MTCategoryLabel$></a></li>
</MTCategories>
</ul>

The best way to explain what’s going on here is to show what this will come out to on the actual page (obviously I’m inventing categories here; I am also truncating the URL to the archives for readability):

<ul id="poetslist">
<li class="academia"><a
href="http://archive/cat_academia.html"> Academia</a></li>
<li class="garcilaso_de_la_vega"><a
href="http://archive/cat_garcilaso_de_la_vega.html"> Garcilaso de la Vega</a></li>
<li class="perseverance"><a
href="http://archive/cat_perseverance.html"> Perseverance</a></li>
<li class="tennyson"><a
href="http://archive/cat_tennyson.html"> Tennyson</a></li>
<li class="yeats"><a
href="http://archive/cat_yeats.html"> Yeats</a></li>
</ul>

As you see, the category label has been placed into the value of the class attribute. The dirify bit we added into the template ensures that the label comes out without spaces; this is necessary because CSS thinks that class="garcilaso de la vega" means four different classes, which is not what we want here.

Okay, we have the whole category listing, but we don’t want all of it; we just want the poets. How do we swing that? With two CSS rules:

#poetslist li { display: none }
#poetslist .garcilaso_de_la_vega, #poetslist .tennyson, #poetslist .yeats { display: block }

The first rule says not to display any list item inside anything with the id of “poetslist”. The second rule says to display anything inside id of “poetslist” if it has the poets’ class-names attached.

Oo. Conflict. Which rule wins with a poet, since both apply? The second rule will win, because a class name is considered more specific than an element selector. (I admit I haven’t tested this trick, but it ought to work pretty much as written.)

Anyway, there’s probably a better way to do this; the MT SQL-query plugin looked promising. The catch with my system is that every time you add a poet category, you need to pop another selector into the second CSS rule.

Still. This ought to work, and it gets style points for being thoroughly sneaky and underhanded.

This is just to let Tish know I haven’t forgotten about her. I really do want to wait to help her install Movable Type until the next version comes out.

In the meantime, I have been pondering her page design. As much as I like absolute positioning, I think I’m going to do this one with floats. What I hope to accomplish is letting her blog text flow down the side of the picture, and then open out a bit, shortening the width of the sidebar. I can’t see how to do that except by floating both picture and sidebar.

If anybody else can think of a better way, drop me a line or ping this post.

Well, AKMA is humming along with his Movable Type installation, so I’m at loose ends for something to do.

I happened upon Tish in the comments to another site, asking for help with permalinks. I explained a bit about fragment identifiers to her; she got them working, and explained to me that she’d tried a Movable Type install but hadn’t had any luck.

So that’s my next markover project. Rubbing my hands together in anticipation…

Oh, fragment identifiers? This is an HTML thing. Remember how I explained about id and a name? In purely functional terms they accomplish the same goal, marking something to be pointed at from elsewhere. I never talked about how to do the pointing.

To point to a web page as a whole, you simply put its URL in the href attribute on the a element. To point to CavLec, for example, you would use the tag <a href="http://yarinareth.net/caveatlector/index.html>. (Note that in XHTML 2.0, the href attribute will be allowed on practically all elements, not just a, letting you turn anything into a link. Cool, huh?)

To point to part of a page, that page-part has to have either an id attribute or an a element with a name attribute. How do you find out? You have to view source, I’m afraid. A really cool browser stunt would be to have a mode that searches a page for identifiers and then exposes them visually somehow for easy linking. (Sort of the way modern journals put bibliographic information for articles at the bottom of the first page of the article.)

I don’t know of any browser that does this, but perhaps one could write a Javascript gizmo that would do it. This would be a cool thing for ebooks, too—point, click, wham! there’s an XPath/XPointer expression that will reliably take you to that spot in the book. Pretty doable, I think, and it solves the citation problem that ebooks-in-academia users complain about.

Off-track, sorry. Once you have the id or a name value for the page-part you want, you attach it to the page’s URL with a hash mark (pound sign, whatever, a #, shift-3 on most keyboards). CavLec’s archives listing in the sidebar has the id archives, so to link directly there (for some weird reason), you would use the tag <a href="http:// yarinareth.net/caveatlector/index.html#archives">.

The #archives part of the URL is often called a “fragment identifier” for reasonably intuitive reasons. And there you are.

With all the mistakes I made in poor AKMA’s Blogger template, I’m honestly surprised it worked at all.

I fixed the most egregious errors and sent him revisions. Nothing wrong with the design; all the problems were in execution. It’s not even worth discussing what I messed up. Plain old ordinary stupidity, that’s all.

And if that wasn’t enough, I went and forgot my just-changed FTP password on Yarinareth. Lucky I have a nice sysadmin.

Oh, yeah, and the archives look like total garbage. (And the permalinks may or may not work. Think I fixed ’em, but I’m getting kinda squirrelly at this point.) Will fix tomorrow.

I have a report that my RSS 1.0 feed is messed up. Can anyone confirm? Details helpful. It validates on Leigh’s validator, but I know better than to assume that means it’s right.

Well, AKMA has my hastily-hacked-together Blogger template up, and I can already see it needs tweaks. Drat.

Whatever looks bad is my doing. Whatever doesn’t is his. I’ll do something about it this evening, latest.

Three things, really: the left and right columns are too high (increase margin-top or padding-top, whichever I used), and the text in the archive links is too big (font-size, though I suspect the real problem is the selector). That shouldn’t be too hard. The rest of it seems okay.

Though I cringe (as AKMA surely knew I would) to hear anything I’ve done with his template redesign called “art,” I am reasonably pleased with it as craft, and I very much appreciate his kind praises.

I do want to quibble briefly with this, however: ‘Dorothea can explain why things look the way they do, whereas when I edit my page I take a sort of “Let?s see what happens if I put this tag in” approach.’ AKMA? I do the same thing. All the time. That’s how I learn. That’s how lots of people learn. There’s nothing wrong with that.

You’ve had that part of the process hidden from you to a large extent during this redesign, because I didn’t post something until I was reasonably happy with it. The behind-the-scenes fiddling and swearing (I have a terrible mouth on me while I’m coding) you didn’t see or hear, lucky you.

Positioning large chunks of a page using CSS brings out the worst in many coders, not just me. (Bet you were wondering how I’d segue into the main topic, huh?) A few central notions, however, suffice to permit individual experimentation and appropriate expostulation.

HTML was originally envisioned as presenting very sequential kinds of texts, like papers in scientific journals. The only way to move out-of-line was via the hyperlink. Save for that, elements simply marched down the page one after another. Nothing wrong with that—it’s just boring. That’s why papers in scientific journals do it. (Isn’t it?)

There is, however, one gaping hole in the otherwise-sequential presentation of material in HTML: the table, which presents things side-by-side as well as top-to-bottom. It didn’t take long for some bright web designer to figure out that table markup could place, say, a sidebar next to the main content of the page. And thus was table-based layout born.

The semantic-markup wonks held up their hands in utter horror at this. Tables mean rows and columns of boring-but-important data, not sidebars and cute little menus, they cried. And they looked at the CSS working group and sternly said, “Make it possible to do better.”

The CSS working group came up with three (more or less) angles on making layout tables unnecessary. The first I will deal with only briefly, as AKMA’s template doesn’t use it: the single-image background, to an entire page or to part of it. This is set via the background-image property, which takes a value url('URLtoimage'). The background-repeat property controls whether the background appears once (value no-repeat), repeats horizontally only (value repeat-x), repeats vertically only (value repeat-y) or repeats both horizontally and vertically (value repeat). The background-attachment property (values fixed and scroll) determines whether the image scrolls along with the text or stays fixed in place. (You can see fixed background images in—er, inaction at Stavros’s and Kalilily’s blogs.) Positioning the image on the page is done with the background-position property.

Whew. Enough of that.

The second attack by CSS on layout tables is the float property. This allows you to put one block (such as a pull quote or an image) alongside the block that appears immediately after it in the markup. The possible values are left and right, and they put the floated content to the left or right of the following content, respectively.

Floats can be used for major chunks of a page such as sidebars—CavLec’s sidebar used to be a float—but they aren’t ideal for the purpose. For one thing, they constrain the order of the major chunks of your markup, which may not be desirable. For another, as I learned with CavLec, large floats can take a while to render, and some browsers make them do weird leaps across the page. Play with floats by all means, but I don’t recommend them as your principal layout device.

What’s left that works? A gizmo called “absolute positioning.” (There is also a gizmo called “relative positioning,” but last I checked support for it was so lacking that I don’t think it’s worth talking about.) This gizmo is what it sounds like. Pick up a block, plunk one corner into a specific spot, set a width, let the browser handle the rest.

To absolutely position a block, set the position property to absolute. Then figure out where you want the top left corner of the block to sit. With a top-level block like a sidebar, you will be figuring this relative to the browser screen; with a block inside another block, you will be figuring this relative to the outer block. You can figure in pixels, ems, percents, or any of the other standard CSS length units. I used ems for AKMA’s page, which worked moderately well after some futzing.

Once you have numbers, set the top and left properties appropriately, set the width property to something reasonable, and there you are.

Or almost. You probably have some overlapping blocks at this point. CSS totally ignores the position of an absolutely positioned block when positioning other blocks on the page, happily allowing one block to run roughshod over another.

There are a few ways to fix this—you could simply absolutely-position everything—but I find that it’s easier to wrap my mind around a layout if the main chunk uses margins rather than absolute positioning to avoid absolutely-positioned chunks to either side.

Say what? Well, say I absolutely position a sidebar with top: 13em, left: 0 and width: 25%, that last meaning I want the sidebar to whack out 25% of the browser screen for itself. If I set margin-left on the main chunk of blog text to, say, 28%, there can be no crashes and I still haven’t needed to absolutely position the main text chunk.

(To absolutely position? To position absolutely? To absolute-position? Sorry, spot of infinitive trouble there.)

You will need to employ the Box Model Hack to fix widths in IE5/Win, but you’re probably used to that by now.

Advanced students will want to look into fixed positioning and funky z-index tricks, but be aware that these can bite, injecting nasty unwanted scrollbars and such into your nice layout. With CSS background properties, floats, and absolute positioning, however, most table layouts can go the way of the dinosaur. The sooner, the better.

Did you ever notice how easy it is to use the same piece of markup in more than one blog template? Don’t you just hate it when you have to make the same change to, say, your blogroll in your archive templates as well as your main page? (Said in best Andy Rooney voice.)

Fortunately, Movable Type has a solution to this problem. It’s simple to use once explained, but it can be a little difficult to find and use, so stick with me while I explain it. Those of you who don’t use MT can ask yourselves why not while skipping the rest of this post.

(I meant to post this yesterday, but Murphy’s Web Browser ate one post, and Murphy’s Web Server went flaky last night just as I logged on and tried to redo it.)

If you click on the “Templates” button on your MT buttonbar, you see a list of your current templates. What you probably won’t see (unless you have a super-high-resolution monitor) is the bit at the bottom that says “Template Modules.” This is, however, the bit we want.

Clicking on “Create new template module” brings up a template-editing screen like any other. Give your new module a name (one word is a good idea), and enter the markup in the module-body window. For example, you could put your blogroll sidebar in a template module and call it “Sidebar”. I have. I did so with AKMA’s, too.

You include a template module in your other templates by reference. Open up a template where you want to include such a module. In the spot where you want to include it, type <$MTInclude module="nameofmodule"$>. For our sidebar above, the code would be <$MTInclude module="Sidebar"$>. Really pretty simple.

Now every time you make a change to your blogroll, you make it in one place—the template module—and it propagates to every template the module is included on.

I know Greymatter has similar functionality, but I don’t know about Radio. Helpful little trick, though.