Caveat Lector

In hopes that making this list public will actually shame me into putting a dent in it, here are all the things I want to get done in the reasonably immediate future (in no particular order):

• Finish writing a story for my gaming buddies.
• Finish, test, and debug roustmaps.py, the next chunk of my RoustaboutXT suite.
• Order a Kinesis keyboard. (I finally said to hell with it. The keyboard costs about as much as a single doctor’s appointment, and is likely to help considerably more. Plus, I hurt, damn it, every day now, and it gets in the way.)
• Put the D&D3 stats I generated for the gods of Pegana into HTML and get them up on Cosmic Rooster (warning Aug 2002: link will 404: check Yarinareth main page) .
• Write an ebookweb article on choosing conversion vendors. (I guess I just can’t resist tweaking ex-employers.)
• Gather sufficient information about Blogger to answer AKMA’s question about his blog not validating.
• Blog some more about book people and ebooks.
• Try to dig up some job leads for a friend of mine who needs them. (He is a gonzo VBA for Word programmer, a Quark expert of experts, knows XML, HTML, and CSS, put together his own Linux box, and is the nicest guy you can imagine. Got anything in Madison WI for him? Drop me a line and I’ll put you in touch.)

AKMA, certainly you can put off making your page validate for now. A non-validating page won’t kill you; it just cuts down some on your readership and makes your load and render times a bit longer.

Whether you can fix the page depends on how much control Blogger gives you over your blog template. I don’t actually know how much control that is, which is why I need to do some research into Blogger.

Should Blogger allow sufficient control, you would frankly do best to start over from scratch; the current HTML on your page is horrendously complicated, and it’s always easier to write clean pages from zero than to clean up somebody else’s cruft. Note that I’m not saying you need to rethink the look of the page—just recreate that look using different techniques.

What I could do, again assuming Blogger grants sufficient template control, is come up with (and document for you so you understand what I did) a CSS and XHTML template that looks as nearly as possible like what you’ve got now. Mark Pilgrim would do a better job—I am a rough-and-ready CSS coder at best—but you don’t have anything there that’s all that unusual. I think I can handle it.

So shall I add that to the to-do list? I would be happy to help, sir.

Turns out Blogger templates work pretty much the way my own blogging tool, Movable Type, does. It’s just a matter of finding documentation of the special Blogger blog tags.

So, AKMA, if you want an HTML revamp, it’s yours. You can help me by sending me a copy of your blog template (a cheap and easy way for me to figure out which blog tags you’re using where), but it’s not necessary. Let me know any changes you want to the look of the page, also. Fonts, heading sizes, colors—that stuff’s easy, and the way I do it it’s also easy to change your mind later. So have a ball.

Oh, and what’s tenure policy at the University of Blogaria? (What the heck, it’s the only academic appointment I’m ever likely to have.)

You are a brave man, AKMA. Trusting your well-known and well-loved blog to some Wisconsin weirdo you’ve never met.

But then, you are chancellor of the University of Blogaria, and I want to make full professor someday (I assume everyone starts at Assistant?), so… Quite intelligently, you asked me in email not to just up and do everything for you, pat your head, and go away. You want to know what I’m doing, so you can fix or even redo it yourself.

I wish all the folks I’ve dealt with in publishing houses were like you. I truly do. In case you didn’t already know it, you rock, AKMA.

Because there are plenty of other people in your position who might learn from your site redesign, I see no reason not to talk this through publicly. (Heck, I expect we’ll get all kinds of help that way.) I am certainly not doing this to embarrass or provoke you, and if at any point you want me to take my work off-blog, I will happily and immediately do so. (Ditto, of course, if you decide I’ve done enough and you want to do the rest yourself. That would be a lovely outcome, in fact.)

Your current blog template, AKMA, is set up as one big giganto-table, with several smaller tables inside. This is a time-honored HTML technique which came about in the first place because it was the only way to do anything vaguely resembling a complex liquid layout on the Web.

Unfortunately, this technique suffers from several drawbacks, including lousy accessibility, tag abuse (tables ought to present data that make sense as tables, not be a layout device), and worst of all from your perspective, truly terrible human-readability of the underlying HTML. You played with your template—was it easy? I can’t imagine it was. Following layout-table code gives me headaches.

What we’re going to start with, then, is dumping the giganto-table. To do this, we figure out the main areas of your page. I see five: the header containing the blog title, the left column with links, the middle column with blog entries, the right column for archives, and the footer (the Site Meter stuff, your taglines, and your signature). If you see more, let me know.

In the new AKMA page, each of these areas will be surrounded by a set of <div></div> tags. (In HTML-speak, <div> means “any kind of block of text that doesn’t have a more specific tag for whatever reason.”) Each <div> tag will be uniquely identified, for two reasons: we know immediately what section of the page we’re looking at as we scrutinize the HTML (try that with a table layout!), and we can apply CSS layout and appearance rules separately to each section we have identified. (The CSS work on your new page will come last, as it’s the fun part.)

So how about this: <div id="header">, <div id="links">, <div id="entries">, <div id="archives">, <div id="footer">. Easier to deal with than masses of <tr> and <td> tags, yes?

Drat. My hand is gimping up again. Um, before I quit, there are two changes I recommend you make right away, even before the full redesign:

• You have two opening <body> tags. You only need one (I will explain why tomorrow, after a bit of a rest). The easy fix is to move the background attribute from the second <body> tag to the first one, and then get rid of the second one.
• Your Site Meter HTML includes a couple of things that want to be comments but aren’t, and are actually showing up on your page. In both cases, the offending bits start with <-- WEBBOT . HTML comments should start with <!-- , not <-- . Insert the exclamation points, and you’re fine.

Shall we adjourn this meeting until tomorrow, Chancellor?

I promised an explanation of the single-ness of the <body> tag yesterday. Here is that explanation.

First, let’s get some terms straight. In the beginning Charles Goldfarb created SGML (Standard Generalized Markup Language). And SGML was without ease of parsing, and many-optioned; and unhappiness was in the soul of web developers. And the spirit of Jon Bosak moved—

Right, right, can the cheeseball King James imitation. Sorry.

SGML and its child XML (Extensible Markup Language), despite their names, are not markup languages, if by “markup language” you mean (as most people do) a clearly-defined set of tags to work with, like HTML, SGML and XML lay out a set of rules by which one may create such a markup language. HTML is a markup language created using the rules of SGML. XHTML is the same (more or less) markup language, created using the slightly-different rules of XML.

The reason I explain this up-front is that as we turn AKMA’s site into XHTML, some of the rules I mention will be rules of XML, and others will be specific to the specific markup language XHTML. I will do my best to make the distinction clear, because once you understand a little about XHTML and XML, you can start to learn about other markup languages created with XML (such as RSS, TEI or RDF). Or even design your own language using XML, if that floats your boat. A three-letter acronym is not required.

Right. Now for the explanation I promised.

One of the rules of XML is that every XML document must be wrapped inside one matched pair of tags.(I am guessing that we all already understand that matching a pair of tags involves using the same name for them and sticking a slash just inside the second one.) In XHTML, that matched pair, unsurprisingly, is <html></html>.

Now, what goes inside that outermost set of tags is totally up to the markup-language designer, just as the tagname itself is. The designers of XHTML tell us that inside <html></html> tags go two things: <head></head> and <body></body>. Both these things are required, and there can be only one of each, and they must be in that order.

How the designers of XHTML tell us this has a lot to do with the test called “validation” that AKMA wants his page to pass. Leaving out the grotty details: in addition to rules for markup itself, XML also has a set of rules for defining constraints on markup, such as those I just described for XHTML. If I describe a set of markup constraints in a form approved by XML, I can take any XML document and have a computer program called a “validator” check that it obeys those constraints. That is validation.

(My sharper-eyed readers may be asking themselves this: if XML has one set of rules for markup, and a given XML-based markup language adds another set of rules on top, can one test a document just for the XML rules by themselves, without worrying about markup-language-specific rules? The answer is yes. Very precise markup-heads will call checking just the XML rules “parsing” and checking the XML rules along with language-specific rules “validation.” In our case, we will want to be sure that AKMA’s page meets both the XML and XHTML rules for markup, so we will be validating as well as parsing.)

(Really, really sharp-eyed readers will have gathered from this that there is no validation without parsing, but there is parsing without validation. If your eyes aren’t that sharp, that’s OK.)

So that’s why AKMA doesn’t want two <body> tags in the same document. XHTML rules say not to.

So let’s start AKMA’s new page with some necessary plumbing, and then we’ll consider how to order the five sections we identified in our opening salvo yesterday.

The first thing we should do is declare to the world that AKMA’s page is an XML document. This is done right at the beginning, with the string [of characters] <?xml version="1.0" encoding="utf-8"?>. This string says “I am an XML document conforming to version 1.0 of the XML specification, and I am encoded in utf-8 encoding.” For now, don’t sweat the encoding thing, AKMA; it doesn’t change anything about how you do your page. Don’t sweat the question marks either. They just are.

Next, we need to declare to the world that AKMA’s page is not just any ol’ XML document, but an XHTML document. This is done with the string <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">. Lot of gobbledygook, that, but it means “My document type, and the name of my outermost set of tags, is html. The constraints on me that my document type imposes can be uniquely identified by the string -//W3C//DTD XHTML 1.0 Strict//EN, and if you want to find a copy of these constraints, it is at http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd.” Again, you can treat the whole thing as boilerplate—plumbing—and be just fine.

Now we can start tagging. The basics of what goes in the head element are fairly well-understood, so I won’t do a play-by-play. What we have, then, is this:

<?xml version="1.0″ encoding="utf-8″?>
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
  <head>
    <title>AKMA’s Random Thoughts</title>
  </head>
  <body>
  </body>
</html>

This will validate (really! try it!), as we now have all the markup that the designers of XHTML say is necessary, but it isn’t terribly exciting, as there’s no text in the body of the page.

So. We know we want the page divided into five sections: header, footer, links, blog entries, and archives. Where we put them visually on the page is up to us (until I hear otherwise, I shall assume AKMA wants them where they are); where we put them in the XHTML document is also up to us. So, leaving visual issues for later, where should we put them in the XHTML document?

Believe it or not, “where our eye meets them on the page in a browser” (that is, starting from top left and moving to bottom right) is probably not the right answer. In AKMA’s case, that would give us header, links, blog entries, archives, footer. Not ideal.

Why not? Accessibility for the visually-disabled. We sighted folk can easily skip our eyes across columns we don’t want to read, such as AKMA’s link list (which even AKMA probably doesn’t read every time). It’s a lot harder—can be impossible, in fact—to do such a skip with a text-to-speech engine, as spoken language is tiresomely sequential.

Take my word for it (for now; I will back up this claim later) that we can place our five sections visually wherever we want regardless of their order in the HTML code. That grants us the ability to order the sections so that a screen reader gets to the good stuff right away. My suggested order, then, is: header, blog entries, archive, links, footer. (Reversing archive and links wouldn’t make much difference, actually. I am simply presuming that people want to read more of AKMA before they hop off elsewhere.)

That gives us the following skeleton-page:

<?xml version="1.0″ encoding="utf-8″?>
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
  <head>
    <title>AKMA’s Random Thoughts</title>
  </head>
  <body>
    <div id="header">
    </div>
    <div id="entries">
    </div>
    <div id="archives">
    </div>
    <div id="links">
    </div>
    <div id="footer">
    </div>
  </body>
</html>

We will populate each of the five sections in turn. Class dismissed.

As would be expected when such a luminary (in several senses of the word) as AKMA hands his site to a cheesehead, the blogiverse is watching. Jonathan Delacour reminds me that accessibility, Python, and OSX guru Mark Pilgrim is keeping an eye on me.

That’s fine. It’s great! I don’t know all there is to know; I will be drawing on Jonathan and Mark and probably people I don’t even know yet to help me as I get out of the old familiar fields of markup and into the wilds of cross-browser CSS support and advanced accessibility concepts. If AKMA’s redesign becomes a blog-community effort, that’s only right and proper.

With my own site, I can cut corners and fool around, and so I have. AKMA’s site needs to be done right. Catch me when (not if!) I do something stupid, and I’ll thank you for it. Publicly.

Jonathan also asked how I chose the Kinesis Contoured over the Maxim or Evolution. My basic problem, as it happens, is abused pinkies (especially the left one) leading to nerve (I assume) problems in the wrist and (on bad days) all the way to the elbow. My current job of Spanish-language data entry exacerbates the situation, as Spanish uses a great deal more “q” and “z” than does English.

I have to unload as much from those fingers as I possibly can. (As it is, some days at work I end up typing nine-fingered, either because my left pinkie starts spazzing or my left forearm starts to burn.) Before I found the Kinesis Contoured, I blogged a suggestion:

A keyboard innovation would help, if anyone had only thought of it: put shift, control, and alt keys underneath the space bar so that they can be thumbed instead of little-fingered. It�s the frequent hit-and-hold motion from my weakest finger that has caused me most damage, all told.

The Kinesis Contoured has thumb keys. The others don’t. QED. If the damage to your hands is different (and I seem to be a mite unusual), you may well make a different choice. DMB Ergo, to whom I am glad to have pointed Jonathan, has a 60-day money-back guarantee on Kinesis keyboards, incidentally. (As does Kinesis itself.)

A review of the Kinesis Contoured will surely be forthcoming. For my own selfish sake, I hope it’s a glowing one.

Our first section of page is the header, containing the title of AKMA’s blog. Lucky us; this part’s easy.

It begins with an image of a fancy cross and some Greek, quasi-transliterated (de-Symbol-fonted, yes?) and un-. Now, it is possible with up-to-date browsers to do the Greek without turning it into an image. In fact, I tried that and almost got it to work. The problem (Mark, Jonathan, you listening?) is not with the Greek; it’s that the top and bottom purple boxes can’t quite be got to line up straight, apparently due to the slightly-different width of the Greek and Roman characters. View source to see what I did (and AKMA, don’t panic; this is ever so NOT final-production-style markup, just noodling). Fix suggestions welcome.

So for now we stick with the image. (Even if the Greek did work, we would still have the image of the cross, of course.) AKMA’s original image markup reads <IMG SRC="http://www.seabury.edu/faculty/akma/doxas.jpg" alt="Concerning Received Opinion" WIDTH="532" HEIGHT="66">. This is good for the following reasons:

• The syntax is clean HTML; everything is spelled right and all the attributes are quoted.
• It has an alt attribute, a valuable accessibility aid.
• It gives width and height dimensions for the image; this helps browsers render the page faster.

However, we do need to make a couple of changes:

• All tag and attribute names in XHTML are lower-case. (Attribute values can be mixed-case.) It helps to be aware that XML is case-sensitive by design, while SGML (with which the pre-XHTML versions of HTML are built) is not.

• We need to add a slash just before the closing angle-bracket of this tag. This is an XML thing. The reason for it is that img elements stand all by themselves, not enclosing anything the way most tag-pairs do. To keep parsers and validators from expecting an end-tag </img>, we pop in an end-slash. (It is also acceptable, by the way, to put an end-tag right after the start-tag. I find the end-slash easier to deal with, though.)

  It is a good idea, though not required, to put a space before that end-slash. Older, non-XML-syntax-aware browsers will still be able to read the tag then, whereas some of them get confused and choke if they encounter the end-slash without a space before it.

I also suggest adding an id attribute, not because I have an immediate use for it, but because it’s just a good habit to get into. In XHTML, id attributes can serve as link targets, so if AKMA were to add a Top of Page link in the footer, he could shoot folks right back up to this image.

In XML, attributes serve as identifiers/link targets when the markup-constraint mechanisms define them as such. (XHTML’s constraints define id in this fashion.) Such attributes don’t have to be named “id,” though they often are. They do have other strings attached, however:

• They have to begin with a letter, underscore, or colon (but using a colon is a Bad Idea; never mind why for now).
• All their characters must be letters, numbers, underscores, colons, hyphens, or dots (again, colons are to be avoided).
• They must be a single chunk of characters; no spaces or other whitespace allowed.
• Most importantly, they are intended to distinguish one element from every other element of the document, so they must be unique within the document. No other tag may use the same string of characters as its identifier.

In this case, “titleimage” seems a reasonably friendly identifier.

So the resulting tag is <img id="titleimage" src="http://www.seabury.edu/faculty/akma/doxas.jpg" alt="Concerning Received Opinion" width="532" height="66" />. Attribute order within a tag, incidentally, is not significant in XML or SGML; mix them up however you choose and it all still means the same thing.

Next we have the title of the page restated as text. This is the big-guns, top-priority, A-number-one most important heading on the page, so we will tag it with <h1>. Since this heading is the only heading like it on the page, we could leave it at that. Again, though, we should add an id attribute, on the off-chance we ever want to link specifically to the page title. The word “title” should do fine.

Resulting tag: <h1 id="title">PERI DOXHS</h1>. We may revisit this later—CSS has a trick by which it need not be all-upper-case—but it is fine as is.

And that’s all there is in the header. AKMA’s page markup now reads like this:

<?xml version="1.0″ encoding="utf-8″?>
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
  <head>
    <title>AKMA’s Random Thoughts</title>
  </head>
  <body>
    <div id="header">
      <img id="titleimage” src="http://www.seabury.edu/faculty/akma/doxas.jpg” alt="Concerning Received Opinion” width="532″ height="66″ />
      <h1 id="title">PERI DOXHS</h1>
    </div>
    <div id="entries">
    </div>
    <div id="archives">
    </div>
    <div id="links">
    </div>
    <div id="footer">
    </div>
  </body>
</html>

At this point we can do one of two things. We can go on to mark up other sections of the page, or we can detour into CSS to get the header looking right. Preferences, AKMA?

Poor AKMA got hit with the dreaded Basement Flood Monster today, and hasn’t had time to run through the information I firehosed earlier.

First, don’t panic. Of course there’s more for me to say at the beginning. Over the next few days, you’ll get the low-level stuff, as much by osmosis as anything else, and I won’t even have to refer to it again. The foundation, or perhaps base, of our markover, if you will. (Thanks for the word, Mark. ROTFL! I never got invited to those slumber parties.) And despite my professorial demeanour, none of this will be on the test, because there isn’t any test.

Second, I think it makes the most sense to stay with your current template until we’ve finished the new one and are sure it will work. Apropos of that, I cordially welcome Phil Ringnalda to the party. He kindly emailed and blogged to give me an advance heads-up about accessibility problems with Blogger’s Javascript-based archive-link mechanism. He also handed me the solution on a silver platter. You are getting five-star service, AKMA, and it isn’t from me.

Third, CSS it is. I will fiddle around tonight, and with any luck come up with something I can submit tomorrow to the sharp eyes watching our progress. (Cross-OS and cross-browser testing and feedback very much welcomed. I do my web surfing in Opera 6 for Windows, though I am eyeing the Mozilla release with interest.)

Fourth, a personal howl of mingled delight and anguish. Quoth AKMA, ever the flatterer:

This is the sort of thing people pay The Big Money for, although then they usually don’t want to know the “why” part.

Well, that’s the rub, ain’t it?

Honestly, AKMA, you don’t have to thank me for this. I am teaching a practical skill I have to an appreciative audience desirous of understanding it and putting the understanding to use, in a completely non-coercive and non-judgmental arena. In the process, I am reinforcing my own knowledge and gaining more. This is my joy. I love it. I don’t need to be bribed with Big Money or lots of praise to do it. You made me very happy by agreeing to let me!

If only there were more such audiences for me. Maybe a few willing to pay. (No kids, no car, no meat, no alcohol—doesn’t take much money to keep me afloat.)

Not much of a howl, that, more of a whimper, but even so. I howled at ebook-dom to let me teach them how the OEBPS works. I knew they needed to know; the trouble a lot of them got into and are still getting into is directly attributable to ignorance. I know it’s within their grasp; nothing about it is rocket science.

No one wanted (or wants) to listen. Too propeller-head, say some. Not relevant to the Real Business Issues, say others. (Well, how are you going to sell ebooks if you can’t produce them, or if production is too expensive to be sustainable because your vendors can use your ignorance to gouge you?)

Worst of all is a deep suspicion that I think some people harbored simply because I was willing to teach. If she’s giving it away, it can’t be worth much. They’d rather go to million-dollar consulting firms with no background in print production or markup, or fast-talk-fast-buck dot-com outfits, or we’ll-do-it-for-pennies purveyors of shoddy work and shoddier business practices, and (forgive my language) get screwed.

I am admitting, finally, that a large part of the reason I let myself drift away from the OEBF was sheer frustration with wilful ignorance. Nobody—nobody—was willing to give me resources and time to teach, much as I was eager to. Even those few who acknowledged the desperate need for teaching wouldn’t or couldn’t help me do it, even so far as to pay my airfare and expenses.

Come to think of it, I’m still a hundred bucks or so in the hole from my last trip to a college campus (no, not the U of Blogaria) to talk electronic publishing. Now, a hundred bucks I can spare and no problem, thank the deity or deities of your choice, but it goes to show.

So I feed my teaching jones this way. Don’t thank me. I should be thanking you for the chance to feel useful, for a change.

Hm. Maybe that was a howl, after all.

After a few rounds of language that AKMA would not approve of, I finished a draft of the CSS for his page header.

Ran into some difficulties of interpretation that our pomo professor should enjoy. In Opera, the page has a thin purple border down the left-hand side of the screen (created by a .gif, as it happens; I did it with a CSS border instead) with a rather nifty short section of horizontal border at the top and bottom. I managed after some futzing to write CSS that allowed Opera 6 to recreate the effect. (Sorry, no screenshots tonight. I used to have WinGrab, but it seems to have disappeared in the Linux laptop hosing of a month back.)

Tried it in IE5 and it didn’t work (the border is OK, but IE5 won’t let the header take a notch out of it). So I took a look at AKMA’s page in IE5, and poof! no border, neither at left nor top nor bottom. Hm. Rather than sponsor a dissertation on cross-browser rendering differences, I’ll simply ask: should there be a thin purple border at left or not, AKMA? (What browser do you surf with, incidentally? I should at least test on that.)

You people who do pixel-perfect web designs for every browser in existence have my deepest respect, not to mention pity. IE5 for Windows is—well, let’s keep the language printable, hm?

Introductory CSS lesson coming tomorrow, I hope. (Easier than what you suffered through today. Promise.)

Cascading Style Sheets is a design language designed to decorate markup. It comes in three versions: CSS1, well-supported but unsophisticated; CSS2, powerful but with buggy support; and CSS3, still being worked on.

The syntax of CSS is not SGML- or XML-based. (The XML-based stylesheet language is XSL, more precisely XSL-FO.) Fortunately, the basics of CSS syntax aren’t hard at all. A fully-articulated CSS rule looks like this:

selector1:pseudo-element, selector2 { property1: value1, value2; property2: value3 }

We’ll take that a bit at a time. The selector represents the markup to which the rule should be applied. The same rule may contain more than one selector separated by commas, in which case the properties in the rule apply to all selectors listed. Especially in CSS2 and CSS3, selectors come in many flavors and can be combined in wild and crazy ways—but as usual, the basics take you furthest:

• The selector for an element is the element’s name. So h1 selects all h1 elements in the document.
• The selector for an element with a given id attribute is # plus the id attribute value. So to select AKMA’s header, which we tagged <div id="header">, we use the selector #header.

• Since (X)HTML tags can’t possibly cover every desirable bit of markup, its designers added an attribute called class to nearly every element, so that special cases of the elements can be grouped together. For example, in this blogpost I am using the code element for both XHTML and CSS constructs, but the actual tag I am using for CSS constructs is <code class="css"> so that I can color them differently.

  The selector for such a class is the dot character plus the name of the class; in the above case, .css. Quite frequently, it pays to combine an element selector with a class selector, e.g. code.css.

  We will probably see rather more of the class attribute as the markover progresses.

A pseudo-element is a little piece of something else that’s been selected, called “pseudo” because there isn’t really any markup there delineating it. The most common pseudo-elements are :first-letter (which is what I use to turn the first letter of each Caveat Lector blog entry large and light grey) and :first-line, both of which are just what they sound like.

A property is one particular aspect of design or layout. Their names will be very familiar to print-production people, even to most folks who fiddle with their word processors. Properties include easy-to-understand things like text-indent, font-size, color, and so on.

“Value” I think is self-explanatory. Different properties take different sorts of values; an appropriate value for font-family will obviously be quite different from an appropriate value for font-size. As we go, we’ll come across plenty of properties and the values they take, and you’ll find that most of them just make sense. Some properties accept “backup” values separated by commas. The commonest of these is font-family because of the uncertainty of finding a given font on a given machine. AKMA’s page title, for example, has the property font-family: verdana, arial, helvetica.

Whitespace inside rules is effectively unrestricted; good use of whitespace makes the rules easier to read.

There is more—we haven’t discussed the notion of a cascade yet—but this is quite enough to get started with.

Lacking permission to quote, link to, or use the full names of the folks who have emailed me, I’ll just use their first names.

Elaine asked whether I had tried setting width explicitly on the character spans to solve the vertical alignment problem with the Greek/Roman banner. Yup. Tried it. Good idea that won’t work. Here’s why (CSS2 rec, section 10.2): “This property [width] does not apply to non-replaced inline-level elements.” In other words, it only works on blocks, not spans.

Kevin pointed out that the problem could be solved with a table. Well… yes… but it’d still be a layout table rather than a data table, and I had rather not mangle the markup that way. Then the spongy thing in my head that occasionally behaves like a brain reminded me that CSS2 has table-display properties, so I don’t have to use a markup table. Because the table-display properties are very poorly supported across browsers, there’s no way we can profitably use them for the immediate case at hand; but I’ll play with it anyway this evening, just to see if I can get it to work anywhere.

Bill reminded me that the <?xml?> declaration I talked about yesterday chokes some current-gen browsers that expect to find nothing preceding the &lt!DOCTYPE declaration. He’s right. My bad. (See, I told you I’d do something stupid.) Fortunately, one is not offending against the spirit of Jon Bosak if one simply leaves the declaration out, which I will do henceforth. I will also adopt a <meta http-equiv="Content-Type" content="text/html;charset=UTF-8" /> tag to contain the encoding information, as the brilliant NYPL style guide (by the brilliant Zeldman) recommends.

Professor Delacour does the screenshots I didn’t of AKMA’s new header and the purple-border issue. In fact, the result in Opera 6 is what I was shooting for at the time, because Opera 6 does the same overlappy-notchy thing with AKMA’s current design. (Please don’t ask me why. I haven’t the foggiest.) So I thought it was intentional and tried to reproduce it.

AKMA, however, informs me that a plain vertical border is all he wants, and so that is what he will have. (I gloss over the Box Model Hack issue, because I ran into some IE5 weirdness last night related to it that I am completely at a loss to explain. Fortunately, doing the border the way AKMA actually wants it should eliminate one use of the Box Model Hack. Yay.)

AKMA’s use of IE5/Mac makes things interesting… the basic issue is specifying font sizes. I am going to go read some relevant back issues of A List Apart, Zeldman’s highly useful web-design weekly, before I opine further. (There may be something that Zeldman and Eric Meyer do not know about CSS. I would not want to bet on it, however.)

Thanks to all who took the time to email and/or blog. I do appreciate it, very much. I respond here instead of individually not because I am horribly rude (though I sometimes am) but because until I get my new keyboard and foot pedal (they shipped today, woo-hoo!) I am trying to go easy on my paws.

Right-ho, back-issue checking done. Rather than try to explain the cross-platform and cross-browser issues with the font-size property myself, I am going to let Zeldman and Todd Fahrner do it.

Zeldman’s article is getting on a bit. I took a look at the section on relative sizing using ex and em units, and saw that the problems with them are limited to IE3 and everyone’s perennial whipping-browser, Netscape 4. Pursuant to reports from Zeldman and others (links not at fingertips, sorry) that use of Netscape 4 is approaching zero these days, I think I am going to go the relative-unit route for font sizing on AKMA’s new page.

Should that fail, I will use Fahrner’s system. The reason I do not adopt it up-front is that it is more verbose, less beginner- and maintainer-friendly.

More on what all this means when I actually get some re-coding done, okay?

The slightly-revamped header is done. If there are no objections to it, I will explain my work later (getting tired, sorry) and then move on to the blog body.

The attempt at making display: table handle AKMA’s text-image once again almost worked. Trouble this time (in Opera) was that I could not get rid of the sliver of white space between the purple rows no matter what I did (and I tried everything I and the CSS2 table recommendation could think of). Don’t try this in IE5/Win. I dunno what IE5/Win is thinking half the time.

Well, I got an unhappy email yesterday complaining about the small text size on Caveat Lector. Aha, said I, it must be IE5/Mac, because on IE5/Mac the text is too small even for me.

So I tried what I was considering doing for AKMA, setting the font size on body to be 1 em (which lets the browser set it to its default font size for normal text) and taking the remaining cues from that. You can all see the result.

Looks OK on IE5/Mac, but Opera and IE5/Win set their default font size mondo-huge. I changed my default in Opera, only to find that I had to change the minimum text size also or small stuff verged on the illegible.

This is not good.

I shall have to revert to Fahrner’s system, Box Model Hack and all. I am doubleplusunthrilled about it, but at least I’m in good company.

I’ll institute the fix tonight, and then get back to AKMA.

So it’s taking me longer than I thought to be satisfied about the font-size thing. I really bloody hate pixels, but I may end up stuck with them.

IE/Mac users, please be patient; I know you’re stuck with microscopic type again. Everyone, I apologize that this simple issue is taking me so long to work out for myself.

While you’re waiting, perhaps you could follow along with Andy Todd, who kindly emailed me the following:

Inspired by your advice I’ve updated my blog. I skipped ahead of the class a bit, but luckily my layout is a lot simpler than AKMA’s and
didn’t need as much work as I thought. I also got a fair amount of help from the css tutorial at http://www.w3schools.com/css/default.asp.

If you want to point people to a simpler example then I’ve posted both
my stylesheet (http://www.halfcooked.com/halfcooked.css) and Blogger
template (http://www.halfcooked.com/blogtemplate.txt) on my web site.
There are also the ramblings of a semi informed css and xhtml convert on
my blog at http://www.halfcooked.com/blogger.html.

Thanks, Andy! (Now you know why it took me so long to acknowledge your email. I was just waiting for a chance to use it to cover up my own lack of accomplishment.)

IE5/Mac users should see a bit of an improvement over last night. It is not, I think, quite ideal, but it ought to be better than it was. Others should see things pretty much normally.

And I did it with ems, by gosh.

Coming soon, then: an explanation of the current state of AKMA’s stylesheet, a discussion of the Box Model Hack we’ve been on about, and some more markup.

Before we talk about the Box Model Hack, we had better sort out what a Box Model is.

Paragraphs, heads, lists and list items, and so forth all have boundaries, boundaries that form rectangular boxes. (Sure, if you don’t right-justify your text, as I don’t, the right edge of the box will look ragged, but there is still a straight edge there past which text floweth not.) The CSS Box Model discusses how these boxes are supposed to be constructed.

Works like this: the content itself has a width (which can be set by the width property). Outside the width of the content there may be padding (set by various padding properties). Outside the padding there may be a border (set by large numbers of border-related properties). Outside the border there may be a margin (set by various margin properties).

None of these things, set on a single block, overlap each other. Let’s try a visual. The light gray inside the black border is the padding area; the dark gray outside the black border, the margin area.

Picky design note: If you have a border around something, the choice between margin and padding is obvious: do you want the extra space outside or inside the border? Without a border, the choice is less clear, and often it makes no difference at all. One good thing to know, though: the vertical (not horizontal) margins of two contiguous elements collapse; the padding does not. Say that I set the bottom margin of h1 elements to be 2 ems, and the top margin of h2 elements to be 1 em. The margin between an h1 and a following h2 is 2 ems, not 3; the browser chooses the larger of the two contiguous margins, and uses that. Whereas if I had set equivalent padding, the space between would be 3 ems (probably too large!).

Another good thing to know is that an element’s padding will have the same background color as its content, whereas its margin will not. The margin is transparent, so it will be the background color of whatever surrounds it (typically the color of the page).

Now for the hack. IE5/Win gets the model I just expounded completely, utterly, tragically wrong. (IE6, I am given to understand, gets it right as long as there is no &lt?xml declaration present.) To IE5/Win, the width property includes the width of the padding and border. This can make a huge difference in how wide something turns out to look; the larger the something (say, the body section of a blog), the worse the error tends to be.

Fortunately, it is possible to fake out IE5/Win with one value and let other browsers see the real value. I see no point in explaining how this trick works; it’s enough that it does. Read the details from Tantek Çelik himself, the hack’s discoverer.

While considering the next bits of markup, I noticed that AKMA’s permalinks don’t meet the criteria for proper id values—they’re all digits, and they need to start with a letter.

Question: Will fixing this (which is easy to do) mangle AKMA’s current archive, or will changing the format of the permalink 404 the many, many links to AKMA’s blog?

Phil? Anyone else know?

Pure coincidence, I’m sure, but Zeldman responds today to a heartfelt howl about the difficulties of designing sites in ems.

Sigh. What I may do, when all is said and done, is set the base size on body in pixels and use the Box Model Hack to set a keyword for IE5, then do everything else in ems. Should work. I’ll give it a whirl tonight on Caveat Lector.

The only XML markup I added to AKMA’s header, which he has now graciously deigned to approve, is a style element to contain the CSS declarations. The style element belongs inside the head at the beginning of the page. It should have a type attribute that informs the browser what kind of style information to expect; for CSS, the value should be text/css.

In toto, the style element I added reads like this:

<style type="text/css">
  body {
    background-color: #FFF;
    border-left: 20px solid #90c;
    margin: 0;
    padding: 5px 0 0 0;
    height: 1000% /* temporary, just to show off the border */
    font-size: small;
    voice-family: “\"}\"";
    voice-family:inherit;
    font-size: 12px;
  }

    margin-top: 0;
    margin-bottom: 0;
    padding-left: 1em;
    padding-top: 1.5em;
    padding-bottom: 1.5em;
    margin-right: 30%;
  }

</style>

Three rules there, one for the entire body of the page, one for the header, and one for the title. We’ll go through the properties and values one by one this time; later I’ll probably restrict myself to commenting interesting bits.

I set font-size to 12px, pursuant to the long drawn-out boring discussion of why ems were a bad idea. Because IE5/Win has a known issue (refusing to allow resizing of text sized in pixels), I also used the Box Model Hack to put in a keyword value of “small” intended for IE5 consumption only.

Whichever value a browser uses, all the values for font-size will use it as a base for calculation. Partly, this is because all the other values will be set in ems, not something with an absolute meaning like pixels or keywords. Partly, it is because font size is a heritable value in CSS; larger elements (like big matryoshka dolls) pass their font-size value to the smaller elements inside them.

In practice, you do not need to know all this in order to design with CSS; I only tell you because a few of my current readers have gotten beyond beginnings. In practice, it pays to just dive in and play around. See what happens. The ground-level, intuitive notions of CSS you will gain from such experimentation are worth more explanations than I could give in a thousand years.

Anyway, onward…

The background-color and color values are in hexadecimal RGB. Don’t bother worrying about base-16; find yourself a good color chart. You will frequently see six-digit as well as three-digit values for color properties; to arrive at a six-digit value from a three-digit, simply double each digit (#FFF > #FFFFFF, #369 > #336699). This property also accepts color keywords (though do not expect all browsers to support all color keywords).

It always pays to set margin and padding on the body element to 0 when you start designing a new page. This keeps the browser from imposing its own background color scheme on your hapless visitors. I added 5 pixels of padding to the top of AKMA’s page (when you see four values for these properties, they apply to top-right-bottom-left in that order, just like an analog clock hand), just to be completely sure that the image would never slam into the top of the screen.

The border-left value more or less explains itself: a 20-pixel-wide solid border of color #903 (which happens to be that fetching shade of purple). There is a border property that sets all four borders at once; the margin and padding properties, conversely, can be split into margin-left, padding-top, and so forth.

I set the height value on body to be 1000% of the height of the content just so that the purple border would go all the way down the screen, instead of stopping when the header content was finished. This rule will be deleted when the rest of the content has been placed.

All we did on the header section was set a bit of padding, so let’s move on. Our new properties on the title element are font-weight, letter-spacing, and font-family.

The first one is easy: your basic usable choices are bold and normal. (The CSS2 spec contains other choices, but once more, it pays to stick with the simple stuff.)

The letter-spacing property adjusts the space between individual letters. Typically, the unit you want to use is tenths of an em; fiddle until it looks right. I got the current value directly from AKMA’s original stylesheet, seeing no reason to change it.

The font-family property is one of those that allows backup values separated by commas. So if someone is surfing from a box that doesn’t have Verdana on it, the browser checks for Arial, then for Helvetica, and then (in desperation) uses whatever sans-serif font it has available. Always, always, always put a generic font keyword (your choices are serif, sans-serif, monospace, cursive, and fantasy, but the last two generally lead to weird and unsavory results) at the end of your string of desired fonts.

If there is something I haven’t explained to someone’s satisfaction, let me know and I will try to clear up the problem.

Oh, and thanks to Phil for the answer to my archive conundrum. (Phil? You out there? Your site isn’t responding at the moment, so I can’t get the right URL to your response.)

I got such a rapid and complete response to my previous Blogger question that I’m going to ask another couple. (Phil is spoiling me, I tell you what.)

Does the Blogger interface not provide a separate text input box for the title of a blog entry? The way AKMA’s entries are marked up seems to indicate not. Likewise, can Blogger be tweaked to add paragraph markup, and is it reasonably intelligent about doing so? MT, I have found, can’t quite be trusted; it adds paragraph markup even around blockquote elements and the like, which it shouldn’t.

And a question for AKMA. Phil’s answer to my last question gave us two choices. If we move to using id attributes for your blog entries, you’ll have to brave the slightly-intimidating world of UNIX to ensure that your old archives don’t change their link-target values and break everyone’s links to them. (I will help, of course.) Alternately, we can keep the system the way it is, using <a name="1234567"> to mark link targets. This is legal (but deprecated) XHTML 1.0. It is not legal XHTML 1.1 (which is, believe it or not, the reason I didn’t take you to XHTML 1.1 in the first place; I thought something like this might turn up).

I got no religion either way. I like ids myself, but I don’t think they’re worth making your life difficult over. As Phil hinted, also, you want to think about how often you will revise your pre-markover archives after the template switch. If the answer to that is “Revise? Me? But is my prose not the best of all possible prose to begin with?” then there’s no additional bother using id after the first UNIX hassles. Otherwise, you are probably better off with a name.

(For markup geeks only: The reason id attributes have restrictions that the name attribute on a does not is that XHTML defines them slightly differently. The id attribute is defined as type ID, which forces on it the restrictions I discussed earlier. The name attribute on a is type CDATA, or “character data,” which has much looser rules about its permitted values.)

Update: Thank you, Andy, for the answer to my question: no, Blogger doesn’t do that.

No biggie. We’ll just have to settle on some simple markup rules for AKMA to follow when he writes posts. (I do mean simple. Certainly no more complicated than I use for Caveat Lector—and 90% of the block tags I use for Caveat Lector are plain old <p>.)

Some interesting markover tidbits today. I inadvertently threw poor Professor Delacour into a bit of a tizzy with my note about IDs starting with letters. AKMA also indicates he’s happy without IDs if adding them is going to be an annoyance.

I am of two minds, myself. First mind reminds me that I have no idea why the must-start-with-letter bit is around in the first place. (Steve DeRose tried to explain it to me once, and lost me in a record 3 femtoseconds. Best I’ve ever been able to figure is that without the letter, some stupidly-programmed computers will try to treat the value as an integer rather than a string.) I think it’s a brain-dead idea—when normal humans want to hand a unique identifier to something, they number it, and computers just ought to deal with that.

The other mind wonders why, since putting a letter just before the blog-entry number is dead easy to do in every blogging tool I have ever seen, the templates provided don’t just do it. Why should non-markup-geeks have to worry about stuff like this? Tool should just take care of it. Moreover, I strongly approve of tools adhering to standards whenever they can, and this (as I keep saying) is an easy one to get correct out of the box.

Anyway, I figured out how easiest to handle the id thing. Belt and suspenders. We will put in a new id attribute, appropriately constructed, while leaving the a name the way it was. Permalinks will change to point to ids, so anyone making a new link to AKMA will be assured of long-term link permanence; all old links will work until such time as AKMA decides to remove the a name bit from his template and rebuild his archive. No UNIX futzing with archives necessary.

Something like this, in other words (example only, don’t hold me to it):

<h5 class="entrytitle” id="e1234567″> <a name="1234567″></a>Title of blog entry</h5>

(Professor Delacour, this will work for you too, if you care to try it.)

Which leads relatively neatly to AKMA’s revelation that he will shortly be moving to Movable Type or Radio. Might I suggest that the best time to make the markup change is during the move? Moreover, we should quit worrying about Blogger archive-generation Javascript, and figure out what you want your archive column to look like in your new tool. (New design! Fun!)

I would recommend MT over Radio. Radio has more nifty gadgetry (I hear great things about the news aggregator), but what I have read, particularly at diveintomark’s Weblogging archive, indicates that Radio can be pretty hostile for those trying to build standards-compliant, accessible blogs.

As for ease of installation and use, this non-Perlite had no trouble installing MT and various updates (though I need to update to 2.1 one of these days). I even managed to write a line of Perl to give me Latin date headers.

And on a purely personal note, Ben and Mena Trott are way nicer than Dave Winer. No contest. All things being equal (which I admit they are not in this case), I like to see nice folks win.

This is yet another “how I’m going to do it” post, but with luck there will be a juicy bit or two.

We now have three blogging tools in play, so it seems pointless to work only toward a Blogger template. In any case, checking our results in a browser if all we have is a template is awkward to impossible. Here’s why: the blogtool-specific tags are only occasionally XML/HTML compliant. Any blogtool tag you see with a $ or two in it is not XML; it just looks kinda like it.

This means that it’s impossible to validate a blog template with a typical XML/XHTML validator. You can only validate the results of the template, that is, what happens when posts are fed into the template by the blog tool.

It didn’t have to be this way. XML contains a gizmo known as the “processing instruction” specifically designed for this sort of situation. None of the blog tools I know of use it. Go figure. (What does a processing instruction look like? Well, the <?xml declaration we included and then excluded from our markover template is one. Processing instructions start with <? and continue with the name of the processor at which the instruction is aimed plus a space. They can then contain anything you please except a >, which is the closing character.)

So what I’m going to do is use some of AKMA’s old posts to set up a page that looks like what the final blog will look like. When we’re happy with that, I will translate it into a Blogger template, a Movable Type template, and (assuming I can find sufficient documentation) a Radio template. That way, whatever tool AKMA chooses, he’s covered.

Since I run MT myself, I will also set up a separate AKMA test blog (and give AKMA access to it), to be sure I am handling the template correctly. If there’s a Radio user willing to do the same, I would surely appreciate it.

The next segment of AKMA’s redesign is up, in draft form. I haven’t tested it on IE5/Mac yet; looks more or less OK on IE5/Win and Opera/Win. I couldn’t resist a couple of little design tweaks (I’ll discuss them later), but for the most part I left the design alone. Let me know what doesn’t look right, AKMA, or what you yourself want to change from the original design.

The markup is pretty solidly what I like to see, so examine it (“view source” or “save as HTML” in your browser) and let me know what doesn’t make sense to you. You should find that by and large it’s simpler than what you’ve been doing; most of the complicated markup will end up residing in the template where it belongs, so you won’t even have to remember it’s there.

One thing I may have incorrectly bulldozed, however, is a differentiation among horizontal rules. Are mid-post rules in fact shorter than end-of-post rules? If so, I can allow for that, no problem; I just wasn’t sure if that was the intent.

The CSS is completely up in the air still. Let me know what you don’t like, and it will change.

Looking at my draft for the blog entries, I see three design changes that I made:

1. Entry titles are a touch larger than currently.
2. When a timestamp does not come directly after a date header or blog title, it has some whitespace above it. (How I did this is instructive, and I’ll discuss it in a bit.) In AKMA’s current design, the timestamp has an (IMO) unfortunate tendency to look like part of the previous entry, rather than an introduction to the next one.
3. The permalink/main page links are now in their own paragraph. Just a touch neater that way, plus we can style them separately now.

Any of these changes can be undone, though I would argue pretty strongly for the last one.

The trick with the timestamp: It’s not as simple as just setting a big ol’ top margin. The problem with that is that the margin will still be there after date headers and blog entry titles, and the extra whitespace will look just plain dumb. Fortunately, we can fix that, in most browsers anyway. (Hello? Microsoft? CSS2 selectors in IE/Win, please?)

CSS2 contains the + selector, which joins two other selectors and means “the second selector, when it immediately follows the first one.” Which seems weird, but watch it work. I set a margin-top: 4em on the selector .blogtime (hm, perhaps I should change that to .timestamp, since that is how I am referring to it). Now, we don’t actually want such a big top margin when a timestamp follows a date header (coded as <h2 class="dateheader">) or a blog entry title (coded as <h3 class="blogtitle">). Here is the rule that accomplishes that:

.dateheader+.blogtime, .blogtitle+.blogtime { margin-top: 1em }

I thought I might have to Box Model Hack this for IE5/Win (which understandeth not +), but it seems to look all right. Not entirely sure why, but I’ll take serendipity when I can get it.

Some other tidbits of possible interest (view source on the test page to see them):

• The belt-and-suspenders id/<a name> system is in place. I put the identifiers on the timestamp rather than the blog entry title, because AKMA does not always title his entries, but the Blogger template always puts a timestamp on.

  (For those who missed the earlier discussion: the entry identifiers in AKMA’s current template cannot be used as XHTML id attribute values because they don’t start with a letter. Changing them, however, will break all the links to the archives, not a good thing. So the new template will have both legal ids and <a name> elements per the old template. From now on, permalinks will use the id attributes. Both old links and new ones will work.)

• The timestamp in the current template is indented with non-breaking spaces in the markup. (View source on AKMA’s blog to see them.) Messy. I took them out and used the CSS text-indent property instead. (margin-left or padding-left would also have worked.)
• Some minor cleanups in the markup: all <p> tags now have corresponding </p> tags, a lot of unneeded <br> tags are gone, all tag names are now lowercase, and… really that’s about it. The code was pretty clean to start with. I have definitely seen worse. Much worse.

The next step (assuming all this is more or less acceptable) is turning it into Blogger, MT, and Radio templates. Give me a few days on this one; I still have to read up on Radio.

There are of course a million reasons. I rediscovered one tonight as I worked on a Movable Type template for AKMA. (Got the Blogger one done for the page parts we have so far. Up tomorrow, I hope.)

When you help someone do something, you learn more about it yourself.

I discovered tonight that Movable Type lets me override the default entry order on archive pages as opposed to the main page, something I had rather wanted to do but hadn’t R enough of TFM to figure out how. (For others in my shoes: add sort_order="ascend" or sort_order="descend", whichever is appropriate, to the <MTEntries> blogtag.) Now I know. And have done so. The archive pages should now be much easier to follow. (And Jonathon, I fixed the problems with the category archives while I was at it. Thanks for pointing them out.)

Kevin, in the guise of humble chela, is pointing up holes in my design-guru imposture via email. The absolute positioning of the right-hand panel is causing various different problems in various browsers. Hmph. I may go back to floating the durn thing; had that working, at least.

Ah, well. Web design. *spit* I need to get back to AKMA’s template. Which, by the way, he is going to rework the visual design of, he says.

Cool. With luck, the markup framework we are working on won’t have to change much. (Reordering bits, if desired, should be a snap.) I thoroughly approve of AKMA trying stuff on his own once he feels ready to. Naturally I’ll give whatever aid AKMA wishes. I also promise to bite my tongue rather than offer too much advice. :)

(What, you thought I was going to throw a tantrum because my redesign won’t be permanent? Nah. Not me. I have a Buddhist husband; impermanence is one concept I managed to osmose from him.)

A while back, I set up a test blog for AKMA here on textartisan. Its main page sample index page now contains a couple of dummy posts (one mine-from-AKMA’s-archives, one AKMA’s) that rely on the new template and stylesheet.

I emphatically disclaim responsibility for the category names. Oh, you can’t see them because AKMA’s current design doesn’t include categories? Whew.

I had one of those stone-cold-stupid hours tonight. I could not figure out why the RSS feeds were working fine but the index page wasn’t showing any of the posts. Well, duh. The settings said to display seven days’ worth of postings, and both postings in the test blog are over seven days old! (Yes, I finagled the date on the “February” post.) Whereas the RSS feeds use the last n entries in the blog no matter how old they are (n is 15 by default; can be changed).

AKMA, if you log on, click Manage Blog, the Templates button, and then the link for the main index template, you can study the MT template. I regret that I have not yet done pretty indenting of the markup there. I should get to that tomorrow.

Right now, though, it is past my bedtime. Would have managed to get more done if I hadn’t gotten bogged down in a stone-cold-stupid moment.

Okay, AKMA, the Blogger template is waiting for you.

I don’t think, however, that I’m going to be able to follow through on my promise of a Radio template. I can’t find the docs I need. My last resort is to pick up some themes and try to dissect them; I’ll let you know how that goes.

It is dispiriting, though, to see a FAQ read: “How do I create my own themes? This is a topic that I don’t feel comfortable writing about yet. I haven’t been able to find a good link at UserLand either.”

Wait—perhaps I found something. Hm. Yes, this is a start. Perhaps I’ll see what I can do with it.

I do get the impression, though, that to the UserLand folks design is something handed down from above. Which is fine if that’s what you want, but I like to live a little closer to the code than that, myself.

Many thanks to Bill Simoni for sending me a complete set of his Radio templates. Should be all I need to do AKMA’s.

Bloggers rock. They just do.

I appreciate the enthusiasm, AKMA, really I do. I don’t deserve it yet, is all.

The basic issue with replacing your Blogger template is that I haven’t coded the whole thing yet; if you use the one I pointed out to you, the blogroll and archive sections of your page will disappear. Very bad thing, that.

You can start adopting some of the markup in my samples inside your blog posts; in fact, I recommend it. It will be awkward at first, remembering to close all those <p> tags, but you’ll get used to it. Eventually I’ll do you up some nice documentation, to make things easier, but better I should finish the templates first.

I am about midway through redoing the links section. Once that and the footer are done, we can move your Blogger template, because the archives section is Javascript anyway. (Since you are pretty firm in your determination to move away from Blogger, I think I will refrain from accessibility-hacking the Blogger archive Javascript.) End of the week okay?

As one would expect, AKMA has Done The Right Thing; he has recommended Movable Type to Seabury. (Biased? Me? Sure I am. My blogtool can beat up your blogtool. Nyah.)

The move, he says, may take place in a matter of days. Er. I had better get on with it, then, hadn’t I?

I’ll have the links and footer Movable Typed and integrated into the Random Test Blog tonight. If I can, I’ll at least do the template markup for the archive column too (it will take a wee bit of R’ing TFM, which is the only reason I’m not promising). And I’ll try to get the weekly archive template together by the end of this week—that’s mostly rehash.

When the flurry is over, I will go back and do the Radio and Blogger versions, for my own enlightenment and possibly that of others.

As I have said, insofar as I program at all I am a Pythonista and not a Perl Monk, but for whatever I’m worth I’ll help with the installation any way I can, AKMA.

Okay, the Random Test Blog now has links and a footer. Tested only in Opera 6/Win and IE6/Win as yet; I’ll check IE5 later this evening.

(Would it have killed Microsoft to put CSS2 selectors in IE6? Really killed them? Honestly! Browser wars ain’t over yet, to my way of thinking…)

I’ll explain what I did when I can do so at length.

The latest Random Test Blog is up, with archive links. I changed the date format to be reasonably internationalized. (I assume Blogger only offers one flavor of date format?)

Yet more thanks to Kevin, who caught me trying to code itty-bitty fonts in ems and told me sternly that they didn’t work in IE5 under OSX. Back to the pixels for me.

Assuming I haven’t committed any other design atrocities… AKMA, aside from changing a few <img> links and the MT defaults to point to your server instead of mine, you have a complete MT index page template ready to go. I should (and will) explain some things about how I constructed it, but it should all make sense after that. I hope.

Whew. I think there’s some apple juice in the fridge calling my name.

The left-hand menu on AKMA’s page presents some informative markup issues, deserving of comment. Before I comment on it, though, let me reassure those of you who viewed source on the latest version of the redesigned Movable Type blog and asked “where did the CSS go?”

It’s still there. It’s included via reference, is all.

There are basically three ways to get CSS into an (X)HTML page. One is to use the style attribute on a start tag within the markup. For example, if I want one particular paragraph to be right-aligned, I can simply turn its start tag into <p style="text-align: right">. Go view source on Burningbird’s blog before she redesigns it to see many examples of this technique.

This is fine for honestly unique, never-to-be-repeated-or-redesigned items (and all denial aside, such things do happen). I used it to some effect in an article of mine; scroll to the brightly-colored examples, which are not images. However, for repeated page elements, or ones you might ever want to redesign, this technique is clumsy, verbose (which also means bandwidth-hogging), error-prone, and hard to read.

Oh, and it’s deprecated (meaning legal but not encouraged) in XHTML 1.1. If the W3C removes it, it’ll be one of their more boneheaded decisions, in my opinion; it does have legitimate uses.

The technique I have been using in AKMA’s redesign until its latest incarnation is the (X)HTML <style> element. This element lives in the <head> of your page and can contain as much or as little CSS as you choose. Note the type attribute, which for our purposes should always have the value text/css.

But what if you want to use the same stylesheet on more than one page? What if you want your blog archive to look basically the same as your front blog page? Do you really have to have the same CSS rules on both pages? That’s a maintenance burden; to change the look of something, you will have to make the same change to the CSS on every page or blog template you have. Yuck.

There is another way, fortunately. Dump the CSS into its own file and simply refer to it in the head element. This is what the latest incarnation of AKMA’s page does, and it is what I recommend doing whenever possible. The reference is done via the same <link> tag that you may already be familiar with due to its use with RSS feeds. The tag on Caveat Lector is typical: <link rel="stylesheet" type="text/css" href="http://textartisan.com/caveatlector/cavlec.css" />. You can steal this tag as is; all you’ll need to change is the value for href.

You can add a title attribute if you wish, though. Advanced students will want to note the media attribute, which lets you use one stylesheet for the screen and another for (e.g.) print. View source for Mark’s blog or A List Apart to see this in action, or read more details in the CSS2 specification itself.

These three techniques do not exclude each other; there is nothing wrong with linking to an external CSS document and tweaking it with additional rules in a particular page’s <style> element. But… but… if the external CSS and internal CSS conflict, who wins?

Take that a bit at a time. If an external stylesheet and an internal stylesheet contain rules pertaining to the same element, the browser has to try to apply all properties in both rules. So if you set margin-right externally and text-align internally on <p> elements, the browser will apply both properties to that page’s paragraphs.

If, however, there is a conflict—you set margin-right: 0 externally and margin-right: 1em internally—the rule that is closer to the markup will win. That is an impressionistic way of stating it, but it’s generally accurate. A style attribute on a given element is closest to that element, so it overrides anything else. A <style> element up in the <head> will defer to a style attribute, but will win out over an external stylesheet.

(CSS gurus will note that I am not dealing with @import. Intentional. Anyone who needs this tutorial of mine probably doesn’t want to mess with @import just yet.)

Before I close this post, a moment of pure victory: in Mozilla 1/Win, the CSS version of AKMA’s image header works perfectly. Hot damn! Oops, sorry, AKMA, couldn’t resist.

Right. Now it’s time to talk about AKMA’s sidebar.

Like most blog sidebars, it is a bit of a grab bag. Contact info, blogroll, blogstickers, odds and ends. That makes it a good exemplar as we try to answer the question “How do I decide how to tag stuff?”

Here’s how I decide, faced with something new. Your mileage may vary.

1. What is this thing? Oh, it’s my email address. Oh, it’s the University of Blogaria listings. Oh, it’s a blogsticker. This question may seem silly, but it helps you clarify the answers to the next questions.

2. What existing HTML construct is this thing like? Well, the email address is on its own line, so it’s kind of like a <p> or a <div>. The UBlog listings have a head, which we will naturally cover with a heading tag. Mostly, though, they are a list with two parts to each list item (the title and the individual holding the title). Hm. <ul> and <ol> only contain a single kind of list item, <li>. There is, however, the <dl> or “definition list” tag, which consists of <dt> (“definition term”) and <dd> (“definition definition”) tags. That’s more like it. We’ll use that.

   What if there’s nothing appropriate? This happens frequently with boxy-like things that include other things. AKMA’s archive links, for example, belong with their heading inside a visual box. HTML has no <box> or <archives> tag. It also happens with spans of text inside a paragraph; a common typographic example (and the semantic markup wonks will kill me for this, but so be it) is putting the first few words of the first paragraph of a new page in small caps or whathaveyou.

   The all-purpose fallback tags in HTML are <div> and <span>. The difference between them is that the former acts like a box or a paragraph, starting on its own line, while the latter acts like emphasis tags, intended for short spans of characters inside larger blocks. If nothing else makes sense, use <div> or <span>.

3. Is there only one of this thing, or more than one? This governs the oft-confused choice between id and class attributes. If there is only one of this thing, like an email address on a single-person blog, slap an id on it. If there is or may be more than one of it, as with a blogsticker, you want to use class.

   Now, neither id nor class is required. If what you’ve got is a straight unordered list with nothing particularly special about it, don’t bother classing it; just use the ordinary <ul> tag. If you think you might link to something, put an id on it even if you might not otherwise do so.

4. Does this thing fit inside another thing, and/or have things that fit inside it? You can think about this visually if you like. Might you put a border around this thing? If so, and it doesn’t already have a container tag you can apply the border property to, you need to put a <div> around it. Might you put borders around the things inside? If so, and they don’t have container tags, they need them.

   I detest the <br /> tag and use it as little as possible. It does not provide any information about the items before and after the line break. Nine times out of ten, it is a vastly better idea to use a class on a set of <p> or <div> tag, and then set the top and bottom margins to zero with CSS. (The tenth time is poetry. I do use <br /> tags for line breaks in poetry, and I rather hate myself for it.)

   In AKMA’s case, all of the UBlog faculty were delimited with linebreak tags, making it impossible to distinguish titles from names. I changed that; the result should prove easier to maintain and style.

And there you are—the nickel introduction to data analysis. (I am only half kidding. Figuring out how to put together a SGML or XML DTD involves essentially the same thought process.)

I have some edits to do to the archive-link part of AKMA’s template, because it is no longer alone in its column. What I will likely do is add a larger <div> around the archives <div>.

I also have an updated CSS, but I haven’t loaded it up yet. I’m expecting a phone call this evening, so I may not get to it, but I’ll try to have a new template up by sometime tomorrow.

I see that I didn’t explain myself very clearly yesterday with regard to the role of <div> and <span>. Let me give it another whack.

If you look at a web page or a newspaper or a book, you see that it is divided up into blocks. Paragraphs, headlines/headings, lists, captions, etc. What all these things have in common is that they are separated from each other vertically. They start on new lines. The <div> represents precisely that lowest-common-denominator aspect of block-ness. All you know about a <div> to start with is that it is a block.

(Why, you may be asking, didn’t they just call the darn thing a block? I suspect, but do not know for certain, that the HTML folks borrowed this notion and its name from the Text Encoding Initiative, for whom it is pretty fundamental.)

If you look closer at individual blocks, you see that not all the text in them is created equal. Some of it is emphasized, even strongly so. Some of it may be small caps or funny colors; on a web page, some of the text may represent a link to somewhere. These standout bits, however, are not blocks; they do not start new lines. They’re just chunks of blocks that happen to be a little different from the rest of the block. Again, the lowest-common-denominator representation of such a span of characters is <span>.

If you are an advanced Microsoft Word or Quark XPress user, you may be comfortable with the distinction between “paragraph styles” and “character styles.” The former are roughly analogous to <div>s; the latter are closely analogous to <span>s. I hesitate to bring it up, though, because there is one key difference between a <div> and a paragraph style: <div>s nest. You can put one <div> inside another inside another ad infinitum. Word and Quark don’t let you do that with paragraph styles.

Nesting <div>s is an important thing to be aware of, because it allows you to model your information much more intuitively, and style it more sensibly. The styling gyrations you have to go through to get space above and below, say, a multiple-stanza poem (which is a block that contains other blocks—stanzas—inside it) in Word or Quark are downright outrageous. In HTML it’s no sweat. You just put each of your stanzas in <div class="stanza"> … </div> tags, and put the whole poem in <div class="poem"> … </div> tags, and with a bit of CSS padding, there you are.

The annoying thing about nesting <div> tags is figuring out where to put the end-tags. Mistakes can be costly. The markup problem in my archives that I fixed this week was of precisely this variety: I left out an end-tag for a <div> in my template, and the result was one heck of a mess. This is one of the few situations in which a genuine XML editor can be useful. It will tell you precisely which <div> it is that is missing its end-tag.

(Yes, I have a generally low opinion of XML editors. They don’t have to be as obnoxious as they are, but the current generation of them is so obnoxious as to be unusable, for ordinary mortals and markup geeks alike. I have high hopes that the Topologi editor will be a large step in the right direction, however, at least for markup geeks.)

Another way to think of a <div> or a <span> is as a proxy for all the wild and wonderful text divisions that HTML simply didn’t think of. Take blogs, for example. HTML predates the blog by a lot. The folks who came up with HTML couldn’t possibly have known that blogs would almost universally contain blogrolls, so they didn’t put in a blogroll tag. So they created the <div> instead, so that bloggers could invent <div class="blogroll"> if they needed it.

But what do you need the <div> tag for? Why can’t you just invent a <blogroll> tag? Ah, grasshopper, now you begin to move beyond the playground of HTML, in which all tag names are fixed, into the wide and wonderful world of XML, in which you may invent all the tags you care to. :)

Clearer now, I hope?

New version of AKMA’s template and CSS up. Some stuff is probably wrong because it’s late and I’m wiped. Plus I have some accessibility things yet to do. But I was two days late with this, and wanted to get something up and running.

Does anyone know anything about a display bug in Mozilla regarding the left margins of lists? AKMA’s archive list entries look right weird in Mozilla, and I don’t think it’s me this time. If you know what it is or how to fix it without messing it up in other browsers, please tell me.

Mark, I’ve been a good little blogger and made all my links bold. I curse the individual who had the idea to underline links. Underlining is just plain ugly, and I’m just enough of a typography snob not to want to do it. Still, accessibility is accessibility, and bold is OK, so bold it is.

The accesskey stuff is right cool. I’ll give that a shot soon, both here and with AKMA.

Eyes… closing… must… go… bed… soon… after I download the next version of MT, though. And I just kicked in fifty bucks. Ben and Mena deserve it and more.

I got the weekly archive page template put together, so I think the architecture of AKMA’s redesigned blog is all set to go. (Barring additional accessibility tweaks, that is. And I want to check the RSS feeds—mine didn’t put the entry IDs on post links.)

When AKMA moves to Movable Type, he should be able to just pick up stuff from here and plonk it down there, barring a few image URLs that don’t point to the right place. If a zip file of the templates is preferable, though, it’s no problem for me to provide one.

I have a fair bit of explanatory work left, so stay tuned…

I can tell already that AKMA is learning some stuff I didn’t explicitly teach. For example, the post on Greek mottoes for Blog U contains Unicode for the Greek, and also deploys Unicode for typographic quotes and dashes. Good job, AKMA! (Now tell me where you went to find the Unicode values you needed. A good table of these things can be terribly hard to find.)

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.

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.

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.

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 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.

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.

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.

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.

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 (&amp;). (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.

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.

A weird problem I’m having with Phoenix lately underscores the desirability of easy-access blog archives.

For some reason, Phoenix is over-relying on cached copies of some blogs. (Yes, tried clearing cache; thank you come again.) Sometimes I can override it by going to the full blog URL instead of the index to whatever directory the blog lives in (e.g. http://yarinareth.net/caveatlector/index.html instead of http://yarinareth.net/caveatlector/).

Sometimes I can’t, and the only way I can read the latest posts is by hitting the archives. (Seems to happen to Blogspot blogs a lot; dunno why.)

I’m gonna pick on Mark here, ’cuz he won’t up and kill me. To get to a particular post in Mark’s archive, I have to click three times: once on the Archives link on the main page, once on the month link, and once on the post I want to read in Mark’s calendar view. (Clicking on a day in Mark’s calendar view only gives me excerpts, not full posts.)

Whereas to read the latest archives on my blog, one need only click the appropriate link in my sidebar.

Not only is Mark’s indirection an annoyance, it’s a waste of expensive bandwidth—diveintomark.org has to serve me up two pages I don’t want so that I can get to the page I do want. I’ll lay odds Mark wastes more bandwidth on these intermediate pages than I do by using weekly archives instead of individual-post archives—though, I hasten to say, there is no way to test this assertion because I don’t even have individual-post archives.

Maybe it’s that I read too damn fast, but individual-post archives never fail to annoy me. When I’m trying to catch up on a blog, as for example after my trip to Indiana a while back, I hate having to click on individual post links. Hate it hate it hate it. Larger date-based chunks, please.

Am I all alone here, or does this irk anyone else?

Well, in response to my question yesterday about preferred styles of archive navigation, seems I am all alone. In fact, the tone of some responses indicates that I am not only alone, my point of view is an offense unto the good names of blogging and information architecture alike.

Seems not unlikely. So I apologize for any offense or confusion caused, and I also apologize to those who find my weekly archive unnavigable.

In my copious spare time, I have been devoting a cycle or two to what I’m going to do to textartisan.com.

Had a thought yesterday that’s just interesting enough to maybe try doing: page is a big square “A”, with the top and sides a contrasting color to the body, and the navbar acting as crosspiece. Should fit nicely with TAG’s logo (which is wizard cool—had it professionally designed a while ago, and am just itching to use it finally), and be a subtle reinforcement of the A-for-artisan idea.

Plus it’s functional and code-able, always a plus.

Still dunno what the color scheme will be, though I’m attracted to warm-tan backgrounds for some reason. I’ll code it up in black-and-white first, worry about colors later.

Simon Willison is doing a really terrific series on CSS web design. Pop by his blog and check it out. Simon writes good tutorial—step-by-step, example-driven, and bloody well-written. I am taking notes—and not on CSS.

Are the blog notification services wonky this week or is it just me? I missed three posts in the series because I didn’t realize Simon’s blog had updated.

I haven’t forgotten about the Movable Type series, by the way. I need to do a couple-three more hacks on my recreation of the default Movable Type design, and then I’ll be ready to get going again.

Well, the textartisan.com markover is almost done, except for the OEB FAQ and testing on Those Other Browsers That Aren’t Mozilla-Based. (Drat them. Wish they’d all go away. It looks fan-frickin’-tastic in Firebird.) I still have to write the contact page and the services page, but I know what I want on them, and they shouldn’t take long.

Once again, I must credit the talented Laura Blalock for shoring up my nonexistent design sense. She really did a phenomenal job.

Update: Okay, the sales pitch is written and up, and now none of the main navigation links will 404. (Or should, at any rate. If one does, something is exceedingly wrong and I would appreciate a quick email.)

I love TAG’s logo. It just rocks my socks. No, I didn’t design it; I could never come up with anything that good. Nicole Bratt designed it. And it’s absolutely perfect. I half think I restarted TAG (aside from tax-accounting issues) just so I could finally use that rockin’ logo.

OEB FAQ. Must redo OEB FAQ. Not looking forward to it. But must. Before next Wednesday. Grrr. Would really like to take it down, as the OEBPS is moribund if not actually buried, but the FAQ has been cited in print and everything, so I don’t quite feel right banishing it into the outer darkness of 404dom.

Internet Explorer version 5 for Windows is, quite simply, the evil and gangrenous spawn of innumerable purulent fiends dwelling in festering miasmas of bile-soaked slime.

That is all.

No, it isn’t. You know what? I’m tempted to figure out how to bar it from my sites. Pfeh. You want to read me, get a real browser or a news aggregator.

I added the “label table” to my growing information-architecture toolbox last week. Genuinely a clever idea, I thought, and simple as only the best clever ideas are.

What you do is make a table of your navigation-link text against the title elements and on-page main heads of the pages it points to. If you’re being inconsistent about what things are called, the label table makes that jump right out at you.

It occurs to me that compiling a label table on an existing site ought to be really bloody simple to program. So simple that I am tempted to program it myself. I’m a wimp about parsing HTML for sense, so I’d probably insist that the navigation structure (whatever it is) have a class attribute whose value is handed to the program as an argument. Algorithm for finding main page head: first <h1> if any present, else largest <font> on page, else first words on page. No worries. And the rest doesn’t seem difficult at all.

Famous last words… and I really don’t have time for this, either. But it’d be a nifty little utility. LazyWeb?

It looks as though the primary documentation we will be handing our InfoArch client is a set of Dreamweaver templates, and while I fully intend to supplement that with real written documentation and plain-HTML templates, I fear I have to give in on this point.

So I have a question for y’all Dreamweaver gurus. Is it possible to make one lone attribute value editable?

The reason I’m asking is that I want to do CSS submenus via IDing the submenus in the navigation bar, and showing them only when that ID matches the value of class on body. (If that was Greek to you: trust me, it works.) But if I can’t get a Dreamweaver user to edit class on body appropriately, all is for naught.

See, this is the danger (she complained bitterly) of hiding code from people. A perfectly simple, easy-to-explain code change—I mean, how hard is it to understand “Make sure the value of class on the body tag matches the section of the website that the new page is part of”—cannot be accomplished because we’re all paranoid about letting people see angle brackets. Oo, scary.

It’s not a huge deal if this doesn’t work out. The menus on this site are simple enough that submenus are gravy, not meat and potatoes. If they get left out, that’s fine. Still, I’d like to make this work, and I can’t if Dreamweaver stands in my way.

Update: All hail the LazyWeb. Two people wrote to say yes, this is possible, but only in the very very latest version of Dreamweaver. To do it, make with the clicky on Modify –> Templates –> Make Attribute Editable. Thanks!

So after class today I hopped into the SLIS computer lab to see if my whiz-bang new design for Info Arch passes muster in IE6.

What. The. EFFING. Hell. Is. That. I swore to myself as the bottom border on the header mysteriously doubled itself (obliterating my quick-links bar), and the submenus swelled to twice acceptable size.

See, this is why I normally do web design in private. I just can’t manage to do it without cussing a blue streak about CSS problems. I apologize to anyone in the SLIS lab this afternoon who had to listen to me.

But I fixed things. Eventually. I have learned that it doesn’t always pay to try to grok somebody else’s CSS hack—just copy it, paste it, and let it run.

As I feared, there’s a slight color mismatch between my nice sidebar GIF and the browser’s background color on some monitors. (Did I mention that I’m not a graphic designer and don’t understand color theory?) But it’s not perceptible enough that I’m going to fuss over it.

Oh, and I have to actually give Dreamweaver some props. Yes, really. Turns out, if you set up CSS distinctions based on class and id, Dreamweaver is smart enough to figure out which elements you’ve used that set of attribute values on. If you click on the element, right-click on it in the bottom pane, and select “Set class to…” you get the appropriate list of classes. This is actually pretty darn cool. Go Dreamweaver.

Addendum: I feel slightly better at not being the only coder whose language turns color: blue on occasion. And in other news, my quicklinks bar has broken… again…

It’s eminently possible to be too clever for one’s own good.

I did a slick little trick for Info Arch client’s site involving turning a thick border into an ersatz navigation bar via relative-positioning the list of links. After much futzing, finally got it working a treat. (Except in Firebird on Win98. Still don’t know what the heck was up with that.)

The problem was that the bar was so thick it had become the dominant visual element on the page, quite overshadowing the (very slick—I can say this because I didn’t design it) logo and the nice swooshy sidebar.

This, one of my groupmates pointed out to me gently, was not good.

Well, okay, I can slim the bar a bit… maybe cut the font size… wait a minute. This is silly. Start over. Start OVER.

Five seconds later, I’d dumped the border and the relative positioning and redone the bar with thin top and bottom borders and the same unobtrusive background color as the navigation sidebar. Much, much better-looking and more reliable, though oozing much less cleverness.

Hey. Maybe the gray instead of the green for the borders there, since the page is so green-heavy… I’ll see. Either way, less cleverness meant a better-looking page.

Eventually I shall be clever again, I’m sure. Fear me…

So I’ve been given more or less carte blanche to design something for the Wisconsin Historical Society’s new intranet. Make it pretty, he said.

Well. Um. Okay. So not a web designer.

But I like some of the sites I see that use a photo affixed to the viewport as background, so I went cruising for suitable photos. I should learn not to do this. I could get lost for years in all the cool photos they’ve got.

Finally I stopped myself. What I need, I said, are pictures of and from the buildings. That only makes sense. One click back to the home page, one click to “About Us,” and boom, there’s the link I want, to pictures of the very impressive WHS building. (Hear me, Jim? The navigation’s grand.)

Oh, but then I find a link to pure unadulterated inspiration. What a rush. Seventeen different flavors of design “bingo!” I purely love mosaics, I purely love printer’s marks—and the colors on these ought to be fantastic as grounding for a web page.

Knowing me, I won’t be able to make it work. Still. I love a good moment of inspiration.

A couple of tolerably good accessibility articles over at this month’s First Monday. As they read rather similarly to my own (right down to praise of the Government Publishing Office!), I am tempted to simply up and post my own over at Text Artisan Guild, which hasn’t seen any new content (shame on me!) in a long time.

I mean, yeah, I could do the whole journal-submission thing, but, you know, ugh. It’s an article of limited temporal interest, and I frankly don’t have the patience to go through publishing hoops when I’m not forced to it. (Yet another reason Dorothea should stay the hell out of academia.)

So maybe I’ll just post it. I need to tweak the CSS over at TAG anyhow; some things got disarranged somehow during the host move. (I ought to rewrite a bunch of TAG’s sales copy, actually—but talk about things I don’t have patience for…)