Linkdump: Contrarians and Barbarians

  • Fortune Magazine: Is a Futures Market on Terror Outlandish?

    Yet another mainstream publication stumbles upon’s patented technique of writing contrarian articles that trample both logic and good taste in order to draw a few extra readers. On message boards this is called “trolling“; on Madison Avenue, this is called “guerilla marketing”. Dude, Fortune — when the Cato Institute is crapping all over your market-based solution, it’s time to pick up your marbles and go home.

  • Speaking of good ol’ contrarian, it turns out they’re (surprise!) rather enamored of the movie Gigli. Although reviewer Charles Taylor deems it a “minor failure”, the film still “deserves credit for its refreshingly frank sexuality.” Heh. If “It’s turkey time! Gobble, gobble!” constitutes “refreshingly frank sexuality”, you Earthlings are straaange cats indeed.

  • John Gruber solves his labor shortage problem in Code Monkey:

    See, back in 1998 I became the owner of a South American woolly monkey, whom I named Paco, with the intention of training him to assist in my freelance graphic design work. Everyone told me this was a terrible idea, that it would not work, that at the very least I would need a chimpanzee or orangutan, that a mere monkey would never be able to do graphic design.

    Everyone in the Bay Area is worried about losing their programming jobs to cheaper labor from overseas. Meanwhile the real danger is lurking right around the corner, brandishing a banana.

  • Darren Barefoot and his Hall of Technical Documentation Weirdness: “Note that I’m not looking for just bad technical writing–there are plenty of examples of that. I’m looking for the inexplicable, the surreal and the strange.” By the way, if you’ve somehow gotten it into your head that all young male technical writers are as suave and handsome as this Darren character… well, you’d be dead right.

  • Speaking of suave and handsome, take a gander at ESPN’s Eric Karabell and DiveIntoMark’s Mark Pilgrim. Separated at birth?? We report, you decide.

  • The Onion, NPR Listener Acquires Kick-Ass Tote Bag
    (scroll to bottom):

    “If I knew listening to Morning Edition every day before breakfast was gonna get me this cool bag, shit, I woulda sent them money a long time ago.” Hasaji added that Renee Montagne’s insightful interview with author Diana Abu-Jaber was “totally off the hook.”

    I think we would all have to agree that Renee Montagne is indeed “totally off the hook.” Still, she ain’t got nothin’ on my Nina.

  • Finally… in case you were wondering, it turns out that Xena Is the Very Model of a Heroine Barbarian:


    I am the very model of a heroine barbarian;
    Through Herculean efforts, I’ve become humanitarian.
    I ride throughout the hinterland — at least that’s what they call it in
    Those sissy towns like Athens (I, myself, am Amphipolitan).
    I travel with a poet who is perky and parthenian
    And scribbles her hexameters in Linear Mycenian
    (And many have attempted, by a host of methods mystical,
    To tell if our relationship’s sororal or sapphistical).


    To tell if their relationship’s sororal or sapphistical!
    To tell if their relationship’s sororal or sapphistical!
    To tell if their relationship’s sororal or sapphisti-phistical!

Yup, I’m out.

Here’s Some Green Ink

Did I say back next Thursday? I meant back next Tuesday.

Today’s business is to wish a hearty Happy Birthday to my friend Marissa. Welcome to your second quarter-century, kiddo — it’s all sagging, mysterious weight gain, and other instances of decrepitude from here on out. Yes, decrepitude. I, for one, have discovered that on a good morning I can run a little over a mile before collapsing in a gasping, wheezing heap. For crying out loud, I was on the varsity soccer team.1 This sucks.

But hey, here’s what sucks worse: somebody decided to give M’ris a a big flaming sack of poop for her birthday. See, Marissa had mused that while writing is a difficult profession, so are all the other professions out there — and that rather than overdramatizing our pain-as-writers, we should take care of business as best we can and move on. Just like nurses, carpenters, Marines, and so on. But no — along comes this gentleman, who insists that no, no no, my pain-as-a-writer is super-special after all. (Fortunately, M’ris can take care of herself just fine.)

This all begs the question — why are people so awfully sensitive about their own writing?

One theory might be that writers are necessarily sensitive, delicate souls who therefore wilt under the cruelties of rejection letters, bad editors, and mean family members.

The problem with this rather romantic theory is that most writers in the Real World aren’t like that at all; or if they are, they’ve learned to deal. In my experience most professional writers quickly develop a thick, crusty shell for protection. If a critique or edit is good, you think about it and incorporate it; if it’s crap, you ignore it (assuming business conditions permit). End of story.

Conversely, non-professionals are usually far more sensitive about their writing than professionals. Take it from me — when an engineer writes a tech paper or a specification, getting him or her to sit down and go over some edits is like pulling teeth. It happens over and over again. One minute, we’re cleaning up some API verbiage; the next minute, we’re in a symposium on the Soul of the Postmodern American Writer with our special guest, Jonathan Franzen.

After several years, I think I’m starting to understand this behavior. Writing is always an ego-intensive process; whether you’re writing fiction or an API specification,2 there’s always a lot of you in there. It’s just that the main difference between professionals and non-professionals is that non-professionals don’t learn how to detach their ego when it needs to be detached.

For this reason, every writer and editor needs a bag of tricks for dealing with bruised egos. Here’s one trick I’ve learned: never edit with red ink. Red ink makes people angry and defensive. Maybe it reminds them of bad experiences in high school English… or maybe red is just an angry color. Either way, I recommend switching to green ink. It makes a world of difference.

However, I’m still up in the air about smiley faces. On the one hand, smileys have powerful ameliorative properties. Just think! — you can transform a proofreading mark that means “This whole paragraph sucks, and we’re dropping it,” to mean “This whole paragraph sucks, and we’re dropping it — but I mean that in the nicest of ways.”

On the other hand, I can’t bring myself to use smileys. Hey, I’m just not That Guy.

1. I didn’t play very much, but still.

2. In some organizations the difference between the two is not as large as you might think.

Back Thursday

Got some bad news earlier today. A very nice lady who I’ve known for three years died of a stroke this weekend. I had gotten to know her through Bill Fredlund’s The Making of the Western Mind classes. She was a vivacious, intelligent, and very fit middle-aged woman — and now all of a sudden she’s gone.

I was all set to write a fluffy little entry this evening about my recent experiences setting up a wireless network in my apartment. But now my heart’s not in it. Maybe in a couple of days.

XHTML2 Explorations, Part II

In the last installment of XHTML2 Explorations, we touched on how XHTML2’s attribute collections provide a rich variety of behaviors for nearly all elements. Today’s installment focuses on the individual elements themselves. As with Part I, this post does not discuss “well-known” XHTML2 concepts.1

New Paragraph Model

XHTML2 gives us a new twist on our old friend the <p> tag. In previous versions of HTML and XHTML, you could not nest other block elements inside a paragraph. Now you can nest any block element except for another paragraph. In other words, you can now consider a list or table to be semantically part of a paragraph.

This leads to an interesting result (first brought to my attention by Jacques Distler). Consider the following (invalid) markup2:

  <p style="color: red">
    Why is Gordon better for Dana than Casey?
      <li>Knows mayor Giuliani</li>
      <li>Can dress self w/o assistance from Wardrobe</li>
      <li>Obvious physical prowess</li>
      <li>Two!! post-graduate degrees</li>

Since a paragraph can’t contain lists, a standards-compliant browser would end the paragraph just before the start of the unordered list. Thus the words, “Why is Gordon…” would be colored red while the list items would remain unchanged.

However, under XHTML2’s new paragraph model this code is valid, and everything inside <p> and </p> would be red. I have to admit that from a coding standpoint, I like this. If nothing else, it matches my naive expectations a little better. (“Hey, why isn’t my list red?” the newbie web designer wonders…)

From a semantic standpoint, I’m a little less sure about this. I usually don’t think of my tables as being nested inside my paragraphs. Neither does Framemaker, for that matter. Is Framemaker broken? Am I broken? Well, maybe. The good thing about this model is that it’s totally optional — you can nest stuff inside paragraphs, or not. Works for me.


You can now nest <script> elements and process them like the <object> element. If the browser understands the parent script, execute it; otherwise go on to the child script(s). It’s a nifty model, albeit one that is not backwards compatible. Whoops — I forgot, it’s not fair for us to harp on that. Sorry. Anyway, the model itself looks good, particularly if you want to script with multiple languages. The spec does take great pains to mention that there are scripting languages besides Javascript, such as… type="text/x-perl". Hmmm.

There is also a new declare attribute for both scripts and objects. This boolean attribute specifies whether the script or object is a “declaration only”, meaning that it is not to be processed until the user initiates some sort of action. And speaking of actions, there’s a brand-new events model defined by the XMLEVENTS standard (which is pleasantly short and easy to read). XMLEVENTS allows you to set any element as the observer or handler for standard DOM events. It also provides a generic <listener> element that can pass events off to handlers. The XMLEVENTS spec looks to be far more comprehensive and flexible than our current model, which involves slathering our code with onmouseover attributes and whatnot. The only catch is that XMLEVENTS has totally replaced the existing model, which means our current scripts all just went POOF!. Argh, there I go again…

The spec also declares the death of document.write:

Note that because of the XML processing model, where a document is first parsed before being processed, the form of dynamic generation used in earlier versions of HTML, using document.write cannot be used in XHTML2. To dynamically generate content in XHTML you have to add elements to the DOM tree using DOM calls [DOM] rather than using document.write to generate text that then gets parsed.

Well, that’s fair enough. The W3C seems to be saying, “Look guys, this is XML here. Not HTML, not some halfway-step that decays back into friendly tag-soup if you make a mistake — this is the real stuff here.” I suppose the real question is whether they’re going to forbid XHTML2 to be served up as text/html. I can’t find any discussion of MIME-type issues in the current spec, so it’ll be interesting to hear the W3C’s final decision on this.


  • There’s a new <quote> element for marking up inline quotes. Unlike its ill-fated predecessor <q>, the <quote> element does not automagically insert localized quotation marks. “We give up,” the W3C is saying. “Insert your own damn quotation marks.”

  • Tables are relatively untouched. The one noticeable change is that the summary attribute is now an element, presumably to provide a facility for richer descriptions. The spec makes no recommendations for how to display this content in visual browsers. I think we can assume that the default should be display: none, but you never know.

    I also noticed that the spec requires tables to have one or more <tbody> elements… but as it turns out, this requirement dates all the way back to HTML4! I must say this comes as quite a shock, given that the validator happily accepts pages with <tbody>-free tables as HTML 4.01 Strict. I’m looking at the spec again right now, and I’m still a bit freaked out over this. Do I not know how to read the spec? Am I hallucinating because I skipped lunch in preparation for the big Fourth of July BBQ? We report, you decide. (Edit: it turns out I can’t read the spec. Never post while under the influence of carbohydrate deprivation.)

  • Finally, Ruby text is now a standard module. This is good news for hundreds of millions of Asian-language speaking users… at least, I think. Actually, this begs the question: if Ruby text is a fundamental component of Asian typography, why are we forcing Asian users to go all the way to XHTML2 to use it? It seems like it would be useful and straightforward to retrofit Ruby text onto HTML. Then again, since HTML is officially a dead specification, the point is moot.


Errr… who needs conclusions? It’s barbeque time. Happy Fourth!

1. My definition of “well-known” is “I remember hearing about it vaguely on someone’s blog somewhere.”

2. As for whether the pro-Gordon argument is as invalid as the markup… well, I leave that as an exercise for the reader.

XHTML2 Explorations, Part I

You read that right: “XHTML2 Explorations”. Yes, the fun never stops here at

I’ve decided to take a closer look at XHTML2, or more specifically, XHTML2 Working Draft 6. I’ll admit that I haven’t done a good job slogging through the thousands of messages on the W3C lists. I’m just a casual observer.

Fortunately, there’s been plenty of weblog chatter over the <object> replacing <img>, <cite> getting dropped and then added back, the excitement over <blockcode>, the battle over the style attribute, navigation lists, the new <h> and <section> model, the “href on everything” model, and more. The Alphas have been discussing these issues for months, and we Gammas have been well-served by just listening in.

But even with all the healthy public discussion, XHTML2 is a big specification (430 KB and counting). At least for my own edification, it’s time to see how deep the rabbit hole goes.

A Swarm of Attributes

XHTML2 provides a huge number of common attributes that are divided up into collections. Most XHTML2 elements accept attributes from all collections. The most well-known example of this is the “everything is a hyperlink” concept, wherein you can turn any XHTML2 element into a link by applying the href attribute.

But of course there’s much more. Consider the set of “common” attributes in HTML 4.01: there’s id, style, class, dir, lang, title, and the “event” attributes (such as onmouseover). This yields a little over 15 attributes, depending on how you’re counting. In contrast, XHTML2 already provides around 30 common attributes. Let’s take a closer look.

The Edit Collection

The Edit Collection provides an edit attribute with four allowed values: inserted, deleted, changed, and moved. Presumably if something is moved, you can specify where it moved to by using the href attribute. There’s also a datetime attribute for specifying the timestamp, the format of which is defined in XML Schema, which references ISO 8601, which has since been revised. Whew.

The default presentation should be display: none for deleted markup, while the other three types should be displayed as-is. Note that if we assume that the XHTML2 browsers of the future will have solid CSS2 support, then we can write:

  *[edit="deleted"] {
    display: inline;
    color: red;
    text-decoration: line-through;

I’ll admit I like the idea of having a simple change record facility. However, there doesn’t appear to be an editedby attribute, which seems like a bit of an oversight.

The Embedding Collection

Through the Embedding collection, each element can have a src attribute. The browser attempts to replace the element’s content with the embedded file or resource. If the embedding fails for some reason, the browser proceeds to process the contents of the element. The spec provides an example involving a table:

  <table src="temperature-graph.png" type="image/png">
    <caption>Monthly temperatures</caption>
    ... (lots of table rows and cells) ...

The spec also declares,

Note that this behavior makes documents far more robust, and gives much better opportunities for accessible documents than the longdesc attribute present in earlier versions of XHTML, since it allows the description of the resource to be included in the document itself, rather than in a separate document.

I scratched my head over the new src attribute for a while… but if you think of it as a replacement for the longdesc attribute, then it sort of makes sense. A couple of points, though.

First, a quibble with the W3C’s example — I’m not quite sure how replacing a perfectly good XHTML table with a PNG image constitutes a great leap forward under any circumstances.

Second, the W3C recommends:

This collection causes the contents of a remote resource to be embedded in the document in place of the element’s content. If accessing the remote resource fails, for whatever reason (network unavailable, no resource available at the URI given, inability of the user agent to process the type of resource) the content of the element must be processed instead.

Maybe I don’t understand this statement correctly, but I take the “instead” to mean that browsers should not continue to process content if the remote resource is accessible. If so, I certainly hope that the browsers ignore this recommendation. The browser doesn’t need to display the child content directly, but it needs to process the entire document and provide access to the child content somehow. Otherwise, accessibility gets worse, not better.

Finally, this concept opens up all sorts of interesting UI issues. Take the <table> example above. If I use my browser’s “Find Text In This Page” function, will the browser search the text in the table cells? How will it highlight successful matches?

The Cite Attribute

The Hypertext collection permits any element to have a cite attribute. At first glance, I thought that this made the <cite> element redundant. But as Mark Pilgrim points out in Semantic Obsolescence:

“No, the cite tag and the cite attribute are not the same thing. The cite attribute is a URL; the cite tag is wrapped around actual names within your text.”

Fair enough. However, I’ve been thinking that this might be an oversight on the part of the W3C, and the cite attribute should be allowed to contain arbitrary text. For example:

  <h1>Ask Dr. Science!</h1>

  <p>Q: Dr. Science, why is the sky blue? -- Ashley, age 8</p>

  <p>A: Glad you asked, Ashley!  The answer is simple, really:</p>

    cite="Jackson, J.D. 1975. Classical Electrodynamics, 2nd. ed. 
          New York: John Wiley and Sons">
    The scattering of light by gases, first treated quantitatively by Lord
    Rayleigh in his celebrated work on the sunset and blue sky, can be 
    discussed in the present framework.  Since the magnetic moments 
    of most gas molecules are neglible compared to the electric dipole
    moments, the scattering is purely electric dipole in character.  In 
    the previous section we have discussed the angular distribution and
    polarization of the individual scatterings (see Figure 9.6).  We 
    therefore confine our attention to the total scattering cross section
    and the attenuation of the incident beam.  The treatment is in two 

The cite attribute provides an elegant way to scope sections of a document as belonging somewhere else, so why limit it only to stuff on the web? As for the <cite> element, it would still be good for explicitly marking up citations (such as the ones found at the end of a journal article). Well, just a thought.

New LinkType Options

The rel attribute, once the sole province of the <link> element and <a> element, is now universal. The allowed values are defined by the LinkType data type. There are three new options:

  • parent: You may now specify a link as a parent document. Strangely, you can’t specify your children or siblings. After all, it’s kinda hard to construct a full tree without information about the children. Oh heck, let’s just say it: won’t somebody think of the children?

  • meta: The link “provides metadata, for instance in RDF, about the current document.” This allows you to place your metadata directly in the body content of your document. Not sure why you would want to do this as opposed to using the good old fashioned <meta> tag, but ours is not to question why.

    Speaking of <meta> element, the spec states that “A common use for meta is to specify keywords that a search engine may use to improve the quality of search results. When several meta elements provide language-dependent information about a document, search engines may filter on the xml:lang attribute to display search results using the language preferences of the user.” The idea that people will provide accurate keywords in the first place, let alone scope these keywords appropriately according to language, seems a quaint notion at best.

  • p3pv1: When I first read this, the first thought that popped into my head was, “What’s the ‘v1’ doing in there?” The second thought that popped into my head was, “What’s the p3p doing in there?” I have no idea why we would want to reference a particular technology here, let alone a particular version of a particular technology. The W3C should rename this one to “privacy” post-haste.

Note: Part II is now available.