We chose Rebecca in honor of Kat’s late grandmother, a grand old lady of enormous chutzpah who taught Kat her near-legendary bargaining skills. The middle name, Alison, honors Kat’s mother, who we’re grateful has lived long enough to receive the honor.

I’m behind on posting this because not only do we have a newborn to handle, but there’s also Carolyn to consider. Carolyn is an amazing big sister and more than eager to help us, but she has a schedule to keep and needs help with some things, as all children do. That makes free time almost totally nonexistent, which means time to write posts is similarly at a premium.

As we gradually settle into a routine, I expect to get back to the things I had cooking, but for now it’s pretty much all in abeyance while I concentrate on our newly enriched family.

Thanks to comments on the previous post in the series, a few elements were added to the list of those which have plausible use cases, and I added some documentation of the elements that either aren’t on the list or don’t need to be on it at the end. Eventually, the “Possible Additions” section will disappear entirely, and at that point I’ll be ready to submit it for consideration to the Working Group.

There are a few outstanding questions raised by commenters on the previous post:

1. Is there a reasonable case for linking any of ul, ol, or dl? In cases where they represent quotations of other documents, they’re be wrapped in a blockquote anyway, and I’ve already got a use case for that one. Linking li makes sense, but the whole list? There are also questions about dd—would it make sense to allow linking to the paired dd?—but I don’t see a use case for dd. The whole point there is it’s supposed to be the definition, not a shortened reference to a longer definition.

2. I was persuaded of the utility of linking video, my previous uncertainty having been based in a misunderstanding of how click-this-video worked now, but what about audio? I haven’t noticed it being common to link embedded audio clips to other sources, but maybe I’m missing something.

3. Can a table have multiple thead, tbody, or tfoot elements? If so, linking them starts to make more sense. I only wish I could find the part of the HTML5 draft that answers this one way or the other. In a like vein, I can’t decide if it makes more sense to add linking to caption or table. I’m kind of tending toward the former. Anyone have good arguments either way?

4. Should embed and object have direct linking, or is that better handled with already-extant markup patterns? (If so, using param, I would imagine.)

5. Is there a reason to link a whole pre to some other resource, other than linking part of a program to a codebase? Because in those cases, I’d probably use the <pre><code>...</code></pre> pattern, and link the code element. pre is a presentational element, really, and you’ll note that I haven’t proposed adding linking to just about any of the presentation elements, sup and sub being the exceptions.

6. There’s a list of “(Possibly) Unsuitable Elements” near the end of the document that might bear some review in case I’m missing some obvious use cases. Obvious to someone other than me, I mean.

Let me know what you think! I’m definitely moving forward with this, as I’ve received encouragement from a member of the HTML WG, but I’d like the proposal to be as solid as possible before I do so. Thanks for everyone’s help!

I have another plugin request, but in this case I’m looking for help in modifying something I’ve already done. Or half-done, maybe.

I don’t know about you, but I get a lot of comment spam. As I type this sentence, Akismet has stopped 837,806 spam attempts in total. A false positive makes it past Akismet and my other defenses to land in the moderation queue about once every four days, on average.

Some of those false positives are really, really, really easy to spot, and they get marked as spam in order to help improve the recognition algorithms. Others are hard to evaluate just by looking at the comment. Many are trackbacks from sites in langauges I can’t read, and others that I can read look legit enough. In such cases, I usually go visit the author’s URL to see if it looks spammy or not.

Now, the way I used to do this was to right-click on the blog link, copy the URL of the target, open a new browser tab, and paste the URL into the address bar. Why? To prevent my WP admin URL from landing in the referer logs of a potentially unscrupulous site owner. But sometimes I forget to do all that, and just click. I figured, well, why not stop fighting the tendency to just click and write a plugin that routes all outbound links through a redirect service?

So I did. You can grab it for yourself if you want, but if you do, understand that it’s pretty clunky right now. Which is the part I’d like help fixing.

The heart of the plugin is simplicity itself:

if (is_admin_page()) {
	add_filter('get_comment_author_url','_mw_obscurify',5);
}

function _mw_obscurify($url) {
	if ($url) return 'http://google.com/url?q=' . $url;
}

There’s a little more to it than that (specifically, the routine is_admin_page(), which I got from someone else’s plugin and wish now I could remember whose it was) but that’s the core. So any time the URL of a comment author is fetched, it’s prepended to turn it into a Google redirect.

That’s true for both href values and displayed URLs, though, which is the clunky part. The end result is that on comments from the aforementioned mighty Hamish, for example, I get the following markup on the “Comments” page:

<a href="http://google.com/url?q=http://hamstu.com">
http://google.com/url?q=http://hamstu.com</a>

What I’d very much prefer is:

<a href="http://google.com/url?q=http://hamstu.com">
http://hamstu.com</a>

Or even:

<a href="http://google.com/url?q=http://hamstu.com">
hamstu.com</a>

So what I’d like to know is if there’s any way to make that happen short of rewriting and replacing get_comment_author_url, which I’d prefer not to do since it could change in future versions of WordPress and I’m not particularly interested in turning a basic plugin into a continuing maintenance headache. I mean, I will if absolutely necessary, but I’d like to find a better way if there is one. Thus the request for help.

Also, are there better redirect strategies than using Google the way I have? It’s very slightly annoying that I have to click through the Google redirect page, and though I absolutely understand why they do that, I’d love to find an automatic redirect that wouldn’t expose my referer to the target site. Anyone know of one, or have a related sharp idea?

I need a WordPress plugin that won’t let me publish a post until I’ve filled in the excerpt field. Anyone got one?

To which I got a whole lot of responses saying, in effect, “Oooo! Good idea! I need that too! Let me know when you find one!” Some of them came from people running fairly high-profile blogs. The need clearly exists. A couple of responses were of the “I could do that!” variety, so I thought I’d post here so as to describe how I think it ought to work from the user’s perspective, and then we can hash things out in comments and someone can code it up and make everyone happy.

So really what I want is, when I push the “Publish” button in WordPress, the plugin checks to see if there’s an excerpt. If not, one of two things happens:

1. The plugin throws up a warning dialog telling me that I’m about to post without an excerpt (again). If I say “Okay”, it goes ahead with publishing. If I say “Cancel”, it returns me right back to where I was, which is the “Write Post” page, with all the data intact and unaltered.

2. The plugin returns me to the “Write Post” page with all data intact and unaltered, and puts an error box at the top of the page telling me I forgot to write an excerpt (again) and that it won’t let me publish until I fix the problem.

One or the other. I think I like #1 a little better, but I’d be good either way. I’m open to other approaches as well, but I don’t think the plugin should rely on JavaScript, as that means leaving out people who don’t enable JavaScript or post from JS-incapable devices.

I would do this myself, but I’m a little wary of the “return to the page with all data intact and unaltered” bit, which I would imagine is pretty easy to mess up. Thus I’m putting it up here as a semi-Lazyweb post so that someone else, someone with more experience with WordPress and plugin authoring, can do it right and quickly.

Okay, who’s on it?

The most recent is a short clip from one of my presentations at An Event Apart back in April, debug / reboot, where I comment at my usual pace on the suppression of quotation marks in my reset styles and why I think relying on browser-generated quotation marks is a bad idea. You also get to see my hair before it got to be the length it is now, which is even longer. There’s a complete transcription on that page, by the way, courtesy Mr. Z.

Then there’s the vaguely silly one, in which I attempt to debug my clothing while sitting in my living room. The main takeaway here, I think, is that my speech patterns on stage are just about the same as those in “regular life”. Pity my family.

So there’s me in the movies. It’s nowhere near as epic-ly mëtäl as some other folks’ videos, but I suppose we all do what we can.

After that comes a much longer section which presents reasons to add linkability to various elements in the HTML5 specification. I did not consider WebForms elements, but instead the list of 91 elements found in the primary list in Simon Pieters’ excellent HTML5 Elements and Attributes guide.

The important thing in that long list is not the exact mechanism I propose, but that I was able to find use cases for 30 HTML5 elements. Each one is described briefly and accompanied by one or two markup examples. Another 18 (listed at the end of the document) seemed initially to be good candidates, but I failed to find reasonable use cases for them. The remaining 43 elements weren’t even considered, since they all seemed to be obviously poor choices. One example is video, which would likely suffer if it were a hyperlink– resolving what to do when a user clicks on the video controls was completely unclear to me.

Now, as to why I’m blogging this instead of taking it to one or another of the relevant mailing lists: I’m looking for community input in order to strengthen the document. Did I miss any alternative solutions in that first section? Are there more pros and cons for the various alternatives? What use cases did I miss in that last list of 18; or, for that matter, what are some strong use cases for the list of 30 that I didn’t include? Are there any elements among the 43 I omitted that do, in fact, have strong use cases for being linkable?

I’ll do my best to keep up with comments. Have at it, folks!

Update 11 Jun 08: I’ve updated the document to incorporate ideas from commenters, and added a few extra bits of information at the end of the document. It’s worth another look, especially since I’ve gotten some semi-official encouragement to submit the proposal to the HTML Working Group.

Here, let me explain by having a pseudo-dialogue with the four reasons.

It isn’t backwards compatible with existing browsers.

Neither was CSS, table markup, PNG support, or any number of other worthwhile advancements in the web. And yes, table markup was an absolutely worthwhile advancement: previous to that, the only way to have a table of data that lined up in any fashion was to space-format it and throw the whole thing into a pre element. Ugly nonsemantic fun!

For that matter, if lack of backwards compatibility is an accepted reason to exclude something from HTML5, then a whole bracket of new elements—like, say, nav, article, aside, dialog, section, time, progress, meter, figure, video, datagrid, header, footer, need I go on?—need to come out of the specification right now. They’re totally unsupported, and may not even be stylable, by older browsers.

(Yes, I just proposed that the term for a group of elements be a “bracket”. A pod of whales, a flock of seagulls, a bracket of elements. Try it out, see how it feels on the tongue. A little angular, perhaps? Don’t worry, you’ll get used to it.)

It adds no new functionality that can’t already be achieved using the a element.

What? What?!?

Given a table where each row contains several cells of of summary data, and there is a desire to be able to click on a row to get more detailed information via a search keyed off that summary information, please explain to me how being able to use <tr href="..."> on each row as opposed to writing a whole bunch of JavaScript to associate a click event listener and delegation code and handler functions and target assembly logic just to simulate what <tr href="..."> would do, were it permitted, constitutes “no new functionality”. Please. I would love to hear that one.

Unless of course HTML5 is going to let us wrap a elements around whatever arbitrary collection of elements we like, in which case, never mind. I’ll just wrap all my trs in as and be done with it. That’d be keen. Will that be possible? Will the HTML5 syntax be so flexible as to permit that?

Yeah, that’s what I thought.

Not that I spent half the week banging my head against this problem and getting a bunch of hand-holding in the arcana of JavaScript and inconsistent browser event handling just to address what twenty-five seconds or so would have sufficed to resolve in an href-everywhere world or anything.

And for the flip side of this, see Wilson Miner’s “Accessible Data Visualization with Web Standards“, where a bar graph is built out of spans so that they can all be wrapped in an a element in order to let you click on any “row”—that is, what would have been a row had he been able to use table markup—and get more information. Yes, absolutely, all that stuff should be in a table, but it was a case of have a table with a bunch of not-that-easy JS forced onto it, or have the contents of every cell in a row be a separate hyperlink to the same destination, or do simple markup with savaged semantics. We shouldn’t be forced into that choice.

It doesn’t make sense for all elements, such as interactive elements like input and button, where the use of href would interfere with their normal function.

True enough. So don’t add it to those elements which would suffer, like input and button. Or, alternatively, define behavior conflict resolution in those cases. There might actually be good reasons to have button accept an href value as a fallback in cases where the normal function of the button fails in some manner.

Either way, the fact that adding href doesn’t work in some cases is no reason to forgo its addition in all cases.

Browser vendors have reported that implementing it would be extremely complex.

I’m always willing to hear why implementors think something is complex to implement, as they’re often subtle and fascinating insights into web browser development. Still, it seems to me that everything ubiquitous href attribution would imply can be recreated with a heavy dose of JavaScript event handlers and related code—(on)click for the sending you off to the target (and any :active-style effects you wanted to bring in), (on)mouseover or plain old :hover for the interactive effects, et cetera, et cetera. Are they really saying that it’s more complex to support this sort of thing in markup than it is to support all the scripting and DOMiness that permits people to laboriously recreate it on their own? If so, why? I’m really curious to know what would make this “extremely complex”, which sounds a good deal more dire than “complex” or just plain old “difficult”.

I’m open to having my mind changed by strong evidence that this would be borderline impossible to implement, even though it can apparently be simulated via existing DOM/JS implementations. Anything short of that, however, isn’t going to convince me that this should be dropped. It was a good idea when it was in XHTML2, and it shouldn’t be abandoned if there’s any chance to save it.

I have a table. (Yes, for data.) In the table are rows, of course, and each row has a number of cells. I want to walk through the rows and dynamically add an ‘onclick’ event to every row. The actual event is slightly different for each row, but in every case, it’s supposed to call a function and pass some parameters (which are the things that change). Here’s how I’m doing it:

var event = '5'; // in the real code this is passed into the surrounding function
var mapStates = getElementsByClassName('map','tr');
for (x = 0; x < mapStates.length; x++) {
	var el = mapStates[x];
	var id = el.getAttribute('id');
	var val = "goto('" + id + "','" + event + "');";
	el.setAttribute('onclick',val);
}

Okay, so that works fine in Gecko. It doesn’t work at all in IE. I changed el.setAttribute('onclick',val); to el.onclick = val; per some advice I found online and that completely failed in everything. Firebug told me “el.onclick is not a function”. Explorer just silently did nothing, like always.

So how am I supposed to make this work in IE, let alone in IE and Gecko-based and WebKit-based and all other modern browsers?

Oh, and do not tell me that framework X or library Q does this so easily, because I’m trying to learn here, not have someone else’s code hand-wave the problem away. Pointing me directly to the actual code block inside a framework or library that makes this sort of thing possible: that’s totally fine. I may not understand it, but at least there will be JS for me to study and ask questions about. Ditto for pointing me to online examples of doing the exact same thing, which I tried to find in Google but could not: much appreciated.

Help, please?

Update: many, many commenters helped me see what I was missing and therefore doing wrong—thank you all! For those wondering what I was wondering, check out the comments. There are a lot of good examples and quick explanations there.

Okay, second’s up!

MW Adminimize (currently v0.5)

This plugin pares down the page-topping links interface that shows up on every WordPress administration page. I got tired of seeing my blog name in Big Huge Letters all the time, and I kept forgetting that the “Dashboard” link was hidden up in that black bar. So I fiddled with some arrays and wrote some CSS, and got something that chews up less screen real estate while also being easier for me to use. Maybe you’ll feel the same, in which case, enjoy the plugin.

In addition to that, I pared down some of the elements of the “Write Post” page so that they took up a bit less space, and compressed the stuff around the post title’s input field. Those styles are marginally less stable and may cause weirdness for you. If so, sorry. Let me know what goes south and I’ll try to get it fixed in a future version.

Oh, and I also included a CSS rule that makes the background shading of moderated comments more obvious, though not in my usual eye-scarring fashion. It’s just a little darker and notably redder. That doesn’t have much of anything to do with minimizing the admin UI, but I thought it was a huge improvement. I might take it out in a future version if the crowd shouts otherwise.

MW Latest Tweet (currently v1.0)

This one does what you’d probably guess: shows the latest tweet. Why not just use something like Twitter Tools? Actually, I tweeted about that. A further survey of the options available turned up nothing that was quite what I wanted. So of course I started hacking away.

The basic mechanism is that any time a page that calls this plugin is loaded, it either returns the last-cached tweet or asks Twitter for the latest tweets so it can cache the latest of them. If Twitter fails to respond (I know, what are the odds?), you still get the cached tweet. This is similar to SimpleTwitter, from which I took much inspiration, but is more advanced in a number of ways. Among the options I wanted to have and thus created was having “human time” intervals as an option, and also the ability to filter out @replies (because I personally wanted to display my latest broadcast tweet, not my latest reply). While I was at it, I decided I’d throw in the ability to define your own XHTML output, so that if the plugin failed there wouldn’t be partial or mangled markup shoved into your pages. Also, since I cache the whole of the latest tweet, you have all kinds of stuff you can output should you so desire. It’s all documented on the plugin’s page.

This is not a widget, because I’ve never written one and didn’t have time to learn (due to all the time I was burning just trying to write the plugin). You have to edit your template/web page PHP in order to call it. That’s just the kind of DIY guy I fly. Er, I am.

Also, I’m a wee tiny bit proud of how I styled the labels on the plugin’s Settings page. I’ll probably write that up in a separate post.

That’s about it. If anything goes wrong or is unclear, please do let me know in the comments. Share and enjoy!

Except in Firefox 3b5, there were no dings, web or otherwise. Instead, some serif-family font (probably my default serif, Times) was being used to display the text “Oy!”.

It’s a beta, I thought with a mental shrug, and moved on. When I made mention of it in my post on the subject, I did so mainly so I didn’t get sixteen people commenting “No Webdings in Firefox 3 betas!” when I already knew that.

So I didn’t get any of those comments. Instead, Smokey Ardisson posted that what Firefox 3 was doing with my text was correct. Even though the declared fallback font was Webdings, I shouldn’t expect to see it being used, because Firefox was doing the proper Unicode thing and finding me a font that had the character glyphs I’d requested.

Wow. Ignoring a font-family declaration is kosher? Really?

Well, yes. It’s been happening ever since the CSS font rules were first implemented. In fact, it’s the basis of the whole list-of-alternatives syntax for font-family. You might’ve thought that CSS says browsers should look to see if a requested family is available and then if not look at the next one on the list, and then goes to render text. And it does, but it says they should do that on a per-character basis.

That is, if you ask for a character and the primary font face doesn’t have it, the browser goes to the next family in your list looking for a substitute. It keeps doing that until it finds the character you wanted, either in your list of preferred families or else in the browser’s default fonts. And if the browser just can’t find the needed symbol anywhere at all, you get an empty box or a question mark or some other symbol that means “FAIL” in font-rendering terms.

A commonly-cited case for this is specifying a CJKV character in a page and then trying to display it on a computer that doesn’t have non-Romance language fonts installed. The same would hold true for any page with any characters that the installed fonts can’t support. But think about it: if you browse to a page written in, say, Arabic, and your user style sheet says that all elements’ text should be rendered in New Century Schoolbook, what will happen? If you have fonts that support Arabic text, you’re going to see Arabic, not New Century Schoolbook. If you don’t, then you’re going to see a whole lot of “I can’t render that” symbols. (Though I don’t know what font those symbols will be in. Maybe New Century Schoolbook? Man, I miss that font.)

So: when I built my test, I typed “Oy!” for the example text, and then wrote styles to use Webdings to display that text. Here’s how I represented that, mentally: the same as if I’d opened up a text editor like, oh, MS Word 5.1a; typed “Oy!”; selected that text; and then dropped down the “Font” menu and picked “Webdings”.

But here’s how Firefox 3 dealt with it: I asked for the character glpyhs “O”, “y”, and “!”; I asked for a specific font family to display that text; the requested font family doesn’t contain those glyphs or anything like them; the CSS font substitution rules kicked in and the browser picked those glyphs out of the best alternative. (In this case, the browser’s default fonts.)

In other words, Firefox 3 will not show me the ear-Death Star-spider combo unless I put those exact symbols into my document source, or at least Unicode references that call for those symbols. Because that’s what happens in a Unicode world: you get the glyphs you requested, even if you thought you were requesting something else.

The problem, of course, is that we don’t live in a Unicode world—not yet. If we did, I wouldn’t keep seeing line noise on every web page where someone wrote their post in Word with smart quotes turned on and then just did a straight copy-and-paste into their CMS. Ged knows I would love to be in a Unicode world, or indeed any world where such character-incompatibility idiocy was a thing of the past. The fact that we still have those problems in 2008 almost smacks of willful malignance on the part of somebody.

Furthermore, in most (but not all) of the text editors I have available and tested, I can type “Oy!” with the font set to Webdings and get the ear, Death Star, and spider symbols. So mentally, it’s very hard to separate those glyphs from the keyboard characters I type, which makes it very hard to just accept that what Firefox 3 is doing is correct. Instinctively, it feels flat-out wrong. I can trace the process intellectually, sure, but that doesn’t mean it has to make sense to me. I expect a lot of people are going to have similar reactions.

Having gone through all that, it’s worth asking: which is less correct? Text editors for letting me turn “Oy!” into the ear-Death Star-spider combo, or Firefox for its rigid glyph substitution? I’m guessing that the answer depends entirely on which side of the Unicode fence you happen to stand. For those of us who didn’t know there was a fence, there’s a bit of a feeling of a slip-and-fall right smack onto it, and that’s going to hurt no matter who you are.

Right now, though, I want to mention a few pieces of news from the conference world. After that, it’s back to steeling myself to upgrade WordPress while stomping out the problems I have with my current install and also, I hope, finally getting it set up to do version-controlled upgrading henceforth.

Right. The news.

• The early bird deadline for An Event Apart Boston 2008 is next Monday, so don’t wait much longer to register if you’re a fan of discounts. If not, that’s cool too. Maybe you like to pay more. We’re not here to judge.

• If you’re on the opposite coast, there’s also An Event Apart San Francisco 2008, whose detailed schedule was announced this morning. It will be two days jam packed with greatness from Heather Champ, Kelly Goto, Jeremy Keith, Luke Wroblewski, Dan Cederholm, Tantek Çelik, Jeffrey Veen, Derek Featherstone, Liz Danzico, Jason Santa Maria, Jeffrey Zeldman, and your humble servant. You’ve still got some time to register with the early bird discount, but I wouldn’t put it off forever, because there’s no way to know when the last seat will be sold.

  (And if you aren’t subscribed to our mailing list, then you’re already behind the times: subscribers got word of the detailed San Francisco schedule yesterday, ahead of everyone else. Because they’re on the ins, as the kids are known to say. Don’t let them have all the fun. Sign up today!)

• At the beginning of June, I’ll be giving a keynote plus a bonus session to be named later at the Spring <br/> Conference in Athens, Ohio. For years they’ve been trying to get me to come down there, and every year I had some insurmountable scheduling conflict. It almost happened again this year, but they were really fantastic and actually worked the schedule to accommodate me, for which I can’t thank them enough. Come on down and take a <br/> with us!

• Come mid-July, I’ll be in sunny Philadelphia for the Higher Education Web Symposium co-teaching a full-day workshop on “CSS Tips & Techniques” with the incomparable Stephanie Sullivan.

• And in the realm of the not-absolutely-guaranteed-and-therefore-underspecified: come late September, it looks like I’ll be back in Destin, Florida; and I just might be making my way to Japan in early November.

Plus of course there’s An Event Apart Chicago 2008 in October, but you already knew about that. The detailed schedule will be published in mid-July, and with that lineup of speakers, I’m already shivering with anticipation.

Okay, that’s all I have for the moment. Hopefully that upgrade/fix/control thing will go less bumpily than I fear, and I can get another post out before all those shows have passed into memory.

Later on, I produced a terse description of line layout which went through a protracted vetting process with the CSS Working Group and the members of www-style. At the time it was published, there was no more detailed and accurate description of line layout available. Even at that, corrections trickled in over the years, which made me think of it as my own tiny little The Art of Computer Programming. Only without the small monetary reward for finding errors.

The point here is that line layout is very difficult to truly understand—even given everything I just said, I’m still not convinced that I do—and that there are often surprises lurking for anyone who goes looking into the far corners of how it happens. As I’ve said before, my knowledge of what goes into the layout of lines of text imparts a sense of astonishment that any page can be successfully displayed in less than the projected age of the universe.

Why bring all this up? Because I went and poked line-height: normal with a stick, and found it to be both squamous and rugose. As with all driven to such madness, I now seek, grinning wildly, to infect others.

Here’s the punchline: the effects of declaring line-height: normal not only vary from browser to browser, which I had expected—in fact, quantifying those differences was the whole point—but they also vary from one font face to another, and can also vary within a given face.

I did not expect that. At least, not consciously.

My work, let me show it to you: a JavaScript-driven test file where you can pick from a list of fonts and see what happens at a variety of sizes. (Yes, the JS is completely obtrusive; and yes, the JS is the square of amateur hour. Let’s move on, please. I’m perfectly happy to replace what’s there with unobtrusive and sharper JS, as long as the basic point of the page, which is testing line-height: normal, is not compromised. Again, moving on.)

When you first go to the test, you should (I hope) see a bunch of rulered boxes containing text using the very common font face Webdings, set at a bunch of different font sizes. The table shows you how tall the simple line boxes are at each size, and therefore the numeric equivalent for line-height: normal at those sizes. So if a line box is using font-size: 50px and the line box is 55 pixels tall, the numeric equivalent for line-height: normal is 1.1 (55 divided by 50).

On my PowerBook, Webdings always yields a 1:1 ratio between the font-size and line box height. The ten-pixel font size yields a ten-pixel-tall line box, and so on.

This is actually a little surprising by itself. The CSS 2.1 specification says:

normal

Tells user agents to set the used value to a “reasonable” value based on the font of the element. The value has the same meaning as <number>. We recommend a used value for ‘normal’ between 1.0 to 1.2. The computed value is ‘normal’.

This is basically what CSS has said since its first days (see the equivalent text in CSS1 or in CSS2 for confirmation) and there’s always been a widespread assumption that, since 1.0 is probably too crowded, something around 1.2 is much more likely.

So finding a value of 1 was a surprise. It was an even bigger surprise to me that this held true in Camino 1.5.2, Firefox 2.0.0.14, and Safari 2.0.4, all on OS X. Firefox 3b5 didn’t render Webdings at all, so I don’t know if it would do the same. I actually suspect not, for reasons best left for another time (and, possibly, a final release of Firefox 3).

Various browsers doing the same thing in an under-specified area of the spec? That can’t be right. It’s pretty much an article of faith that given the chance to do anything differently, browsers will. The sailing was so unexpectedly smooth that I immediately assumed was that a storm lurked just over the horizon.

Well, I was right. All I had to do was start picking other font faces.

To start, I picked the next font on the list, Times New Roman, and the equivalent values for normal immediately changed. In other words, the numeric equivalents for Times New Roman are different than those for Webdings. The browsers weren’t maintaining a specific value for normal, but were altering it on a per-face basis.

Now, this is legal, given the way normal is under-specified. There’s room to allow for this behavior. It’s actually, once you think about it, a fairly good thing from a visual point of view: the best default line height for Times New Roman is probably not the best default line height for Courier New. So while I was initially surprised, I got over it quickly. The seemingly obvious conclusion was that browsers were actually respecting the fonts’ built-in metrics. This was reinforced when I found that the results were exactly the same from browser to browser.

Then I looked more closely at the numbers, and confusion set back in. For Times New Roman, I was getting values of 1.1, 1.12, 1.16, 1.15, 1.149, and 1.1499. If you were to round all of those numbers to two decimal points, you’d get 1.10, 1.12, 1.16, 1.15, 1.15, 1.15. If you round them all to one decimal place, you’d get 1.1, 1.1, 1.2, 1.2, 1.1, 1.1. They’re inconsistent.

But wait, I thought, I’m trying to compare numbers I derived by dividing pixels by pixels. Let’s turn it around. If I multiply the most precise measurement I’ve gotten by the various font sizes, I get… carry the two… 11.499, 28.7475, 57.495, 114.99, 1149.9, 11499. As compared to the actual values I got, which were 11, 28, 58, 115, 1149, and 11499.

Which means the results were inappropriately rounded up in some cases and down in others. 28.7475 became 28 and 1149.9 became 1149, whereas 57.495 became 58. Even though 11.499 became 11 and 114.99 became 115.

This was consistent across all the browsers I was testing. So again, I was suspecting the fonts themselves.

And then I switched from Times New Roman to just plain old Times, and the storm was full upon me. I’ll give you the results in a table.

Much the same happened when comparing Courier New with plain old Courier: full consistency on Courier New between browsers, albeit with the same strange (non-)rounding effects as seen with Times New Roman; but inconsistency between browsers on plain Courier—with Camino yielding a flat 1 down the line, Firefox going from 1.2 to 1, and Safari having a range of values above the others’ values.

Squamous! Not to mention rugose!

Now it’s time for the stunning conclusion that derives from all this information, which is: not here. Sorry. So far all I have are observations. I may turn all this into a summary page which shows the results for all the font faces across multiple browsers and platforms, but first I’ll need to get those numbers.

I do have a few speculations, though:

1. Firefox’s inconsistency within font faces (see Times and Courier, above) may come from face substitution. That’s when a browser doesn’t have a given character in a given face, so it looks for a substitute in another face. If Firefox thinks it doesn’t have 10-pixel Times, it might substitute 10-pixel something else serif-ish, and that face has different line height characteristics than Times. I don’t know what that other face might be, since it’s not Times New Roman or Georgia, but this is one possibility. It is not the minimum font size setting in the preferences, as I’ve triple-checked to make sure I have that set to “None”.

2. Another possibility for Firefox’s line height weirdness is a shift from subpixel font rendering to pixelly font rendering. 10-pixel text in Firefox is distinctly pixelly compared to the other browsers I tested, while sizes above there are nice and smooth. Why this would drive up the line height by two pixels (20%), though, is not clear to me.

3. Much of what I’ve observed will likely be laid to rest at the doorsteps of the font faces themselves. I’d like to know how it is that the rounding behaviors are so (mathematically) messed up within faces, though. Perhaps ideal line heights are described as an equation rather than a simple ratio?

Again, this was all done in OS X; I’ll be very interested to find out what happens on Windows, Linux, and other operating systems. Side note for the Mac Opera fans warming up their flamethrowers: I’ve left Opera 9.27 for OS X out of this because it seems to cap font sizes at a size well below 1000, although this limit varied from one face to another. Webdings and Courier capped at 507 pixels, whereas Courier capped at 574 pixels and Comic Sans MS stopped at 707 pixels. I have no explanation, though doubtless someone will, but the upshot is that direct comparisons between Opera and the other browsers are impossible. For sizes up to 100 pixels, the results were exactly consistent with Camino, if that means anything.

The one tentative conclusion I did reach is this: line-height: normal is a jumbled terrain of inconsistent behaviors, and it’s best avoided in any sort of precision layout work. I’d already had that feeling, but at least now there’s some evidence to back up the feeling.

In any case, I doubt this is the last I’ll have to say on this particular topic.

Update 7 May 08: I’ve updated the test page with a fix from Ben Lowery so that it works in IE. Thanks, Ben! Now all I need is to add a way to type in any arbitrary font-family’s name, and we’ll have something everyone can use. (Or else a way to use JavaScript to suck up the names of all the fonts installed on a machine and put them into the dropdown. That would be cool, too.)

But wait, hold it, never mind, cancel the panic parade: it was not, in fact, the perfect ringtone. Crisis averted! Still, the sinking feeling lingered, reminding me of what could have been, so last night I sat down and got it done. Now I bring to you the absolutely most perfect ringtone ever.

Feel free to preview it using that link, if you really feel that’s necessary, but frankly you should just charge ahead and download the .m4r AAC for instant ringtoniness. If for some reason you’d rather have the audio source and do your own ringtone conversions, you can get the same file as a .m4a AAC or a comfy old .mp3. And for all you completists, there’s a .zip archive of all three formats.

Go. Ring. Enjoy.

Shortly after hanging up, I put in place the temporary home page I’d prepared ahead of time, complete with errors of fact which had grown out of my inability to think clearly about what I knew beyond any doubt was going to happen. The next day, I noticed and corrected the errors, and then realized after a while that my corrections were incorrect and corrected them. Correctly, at last.

When I appended the block of text a day or two later, it was a straight copy-and-paste job, and I was able to avoid introducing errors. I was able to find a perverse solace in that.

To mark this anniversary, I’m publishing the piece I read on stage at Vox Nox 2005, which was the only time it was shared publicly in the last five years. The stunning part, even to me, is that every bit of that piece is the raw, unedited, unaltered truth.

In some ways, I still can’t believe that it’s been five years and that she’s really forever gone, that she’s missed everything that’s happened in my life. In some ways, I can’t accept that she will never know her granddaughter, and that her granddaughter will never know her. And in little ways, I do my best to bridge that yawning chasm with myself and what I learned, what I was taught, over all the years of my life… minus just a bit less than five.

Five years. Five very busy years. Five awful, wonderful, stressful, liberating, irreplaceable years.

I miss you, Mom.

Good for you.

Seriously; no sarcasm or passive-aggressiveness intended. If I thought my reset styles, or really anything I’ve ever published or advocated, was a be-all end-all ultimate solution for every designer and design that’s ever been and could ever be, I’d be long past due for six rounds on the receiving end of a clue-by-four.

Reset styles clearly work for a lot of people, whether as-is or in a modified form. As I say on the reset page, those styles aren’t supposed to be left alone by anyone. They’re a starting point. If a thousand people took them and created a thousand different personalized style sheets, that would be right on the money. But there’s also nothing wrong with taking them and writing your own overrides. If that works for you, then awesome.

For others, reset styles are more of an impediment. That’s only to be expected; we all work in different ways. The key here, and the reason I made the approving comment above, is that you evaluate various tools by thinking about how they relate to the ways you do what you do—and then choose what tools to use, and how, and when. That’s the mark of someone who thinks seriously about their craft and strives to do it better.

I’m not saying that craftsmen/craftswomen are those people who reject the use of common tools, of course. I’m saying that they use the tools that fit them best and modify (or create) tools to best fit them, applying their skills and knowledge of their craft to make those decisions. It’s much the same in the world of programming. You can’t identify a code craftsman by whether or not they use this framework or that language. You can identify them by how they decide which framework or language to use, or not use, in a given situation.

Craftsmanship is something I’ve been thinking about quite a bit recently, as has Joshua Porter. I delivered a keynote address on that very topic just a few days ago in Minneapolis, and my thinking infuses both of the talks I’m giving next week at An Event Apart New Orleans. I’ve started looking harder for evidence of it, both in myself and in what I see online, and I believe striving toward being a craftsman/craftswoman is an important process for anyone who chooses to work in this field.

Because this isn’t a field of straightforward answers and universal solutions. We are often faced with problems that have multiple solutions, none of them perfect. To understand what makes each solution imperfect and to know which of them is the best choice in the situation—that’s knowing your craft. That’s being a craftsman/craftswoman. It’s a never-ending process that is all the more critical precisely because it is never-ending.

So it’s no surprise that we, as a community, keep building and sharing solutions to problems we encounter. Discussions about the merits of those solutions in various situations are also no surprise. Indeed, they’re exactly the opposite: the surest and, to me, most hopeful sign that web design/development continues to mature as a profession, a discipline, and a craft. It’s evidence that we continue to challenge ourselves and each other to advance our skills, to keep learning better and better how better to do what we love so much.

I wouldn’t have it any other way.