December 21, 2002, 12:25 AM ET
Happy holidays
I won't be updating this site for a week or so. As always, I strongly recommend each of the sites in the "Similar sites" list on my home page.
Happy holidays, everybody.
December 20, 2002, 4:53 AM ET
Dynamically labeling blockquotes with CSS
I'm experimenting with using CSS to automatically label blockquotes with their source URLs. Here's an example blockquote:
As ever in web design there has to be a bug and some hacking in response.
If your browser can handle it, you'll see a line appended at the bottom of the quote. That line uses the cite attribute of the blockquote tag to display the quote's source. (See the W3C specification for more on these tags.) It works for me in Mozilla 1.2 and Opera 7, both on Windows.
Here's a screenshot of what it looks like:
Here's the CSS code that makes this happen:
blockquote[cite]:after {
content: "Quote from: " attr(cite);
display: block;
}
In essence, that says, "Let's look at each blockquote in the document. If if contains a cite attribute, let's pop some text after it. Specifically, that text should be 'Quote from: ', followed by the actual contents of the cite attribute (which will be a Web address). And finally, make sure that inserted text appears on its own line."
I also added a bit of formatting. It's pretty self-explanatory:
border-top: 1px solid #669;
color: #669;
margin: 1em 0 0;
padding: .5em 0 0;
font-size: .8em;
font-weight: bold;
I'm not quite sure how useful this is, because the printed URL isn't a clickable hyperlink. (Does anybody know a way to make it so?) In Mozilla 1.2 for Windows, it can't even be selected by the mouse cursor for copying/pasting, so it's doubly unuseful. (It can, though, be selected in Opera 7.) Another potential problem: Long URLs might look funky and break the page layout somehow.
Still, it's always fun to find new ways to use style sheets.
December 20, 2002, 3:33 AM ET
Using 'smart' dates, today
Nathan Ashby-Kuhlman has posted some outstanding ideas on intelligent relative dates. Good stuff:
What if Web sites automatically made dates relative to the current date rather than the publication date? For example, suppose I refer to "Dec. 20, 2002" -- which right now for me is "tomorrow" -- using some JavaScript that will display whatever "Dec. 20" means to you, at the time you access this page.
He offers a JavaScript solution that displays dates in an intelligent, relative manner, according to the user's computer's system clock -- much like Peter Paul Koch's "document last modified" script (and somewhat similar, conceptually, to this site's smart anchoring). Wisely, Nathan points out several problems with this method -- namely the need for editors to tag dates in a special way and the reliance on the user's computer (a problem also apparent in chicagotribune.com's strike countdown a few months ago).
My take: How 'bout continuing to use relative dates ("today" or "tomorrow") in news stories but wrapping them in <abbr> tags that have a title attribute which contains the full date? That way, some of the technical problems Nathan pointed out can be avoided. It'd look something like this:
The code: <abbr title="December 20, 2002">today</abbr>
How it looks: today
This could be a more realistic short-term solution -- although I certainly believe manufacturers of content-management systems should incorporate the feature Nathan has proposed. (On the server side.)
(For more on abbreviations, see my recent entry on that topic. It was posted Tuesday.)
December 18, 2002, 2:00 AM ET
Online chat tool on kusports.com
My first project at my new job debuts Wednesday afternoon. It's a Web-based chat application that simulates a dynamically-updated, real-time chat room -- without using Flash, Java or clunky meta tags. It uses a combination of JavaScript DOM tricks and server-side programming to make dynamic updates.
Most Web-based chat applications, such as washingtonpost.com's Live Online chats, use meta auto-refresh tags to give the illusion of continual updating. Those are easy to implement (a single line of code in your page will do the trick), but they carry major baggage: Every time the page refreshes, the browser must reload the entire page from scratch. Of course, in a chat setting, user-generated content doesn't change; rather, more content keeps being generated. In other words, it's redundant to reload an entire chat if you know none of the text has changed; it's much more efficient to load only the newest stuff.
And that's precisely how the new ljworld.com / kusports.com chat system works. When you join a chat, it'll load all the messages posted up to that point. From then on, JavaScript will make frequent remote calls to the server to check whether any new messages have been posted. Your browser will only have to download a message if you haven't downloaded it already.
It's a lot like Glen Murphy's dchat, which was my inspiration, but there are a number of differences -- namely, chats on ljworld.com will be moderated. (An editor will OK each comment.) Also, the JavaScript degrades cleanly into a meta-refresh page for browser that can't handle modern JavaScript techniques.
The first chat we've got scheduled is Wednesday (today) at 3:30 PM U.S. Central Time. The chat guests are four of the Women of KU (a group of calendar models that our Web site sponsors). Should be an interesting conversation. Check it out, if you've got a chance. It'll be linked off of kusports.com.
December 17, 2002, 2:42 AM ET
How HTML acronyms and abbreviations can help online journalism
Dammit, I'm tired.
Tired of AFI, tired of FEMA, tired of MAC.
I've overdosed on USF and EPA. I can't handle MLB and FDA. BET and SAS don't make things much better.
And I've had more than enough of GOP.
You see, I just can't keep track of acronyms. Unfortunately, though, it seems like every worthwhile news story has one. Or two. Or five.
I understand their allure. Reporters are keen on using them in articles, because they cut on word count and aid the flow of a story. Editors love their compactness when they're tasked with writing a headline that must fit in a small space -- say, a single column of newspaper type.
But for readers, these things can get confusing -- especially when a story juggles three or four of them. Fortunately, HTML provides convenient methods for defining acronyms and abbreviations. Unfortunately, few news sites use them.
For those reasons (and others), every acronym and abbreviation in a news story should be defined.
It's easy to do. (And this is old hat for many Holovaty.com readers, so bear with me.) When you've got an acronym or abbreviated phrase, surround it with either <acronym></acronym> or <abbr></abbr>. Then spell out the acronym (or unabbreviate the abbreviation) and stick that in the title="" attribute, like so:
<acronym title="Bachman-Turner Overdrive">BTO</acronym>
...or...
<abbr title="Sergeant Pepper's Lonely Hearts Club Band">Sgt. Pepper's</abbr>
The result: Users of modern browsers will see the fully spelled-out phrase in a browser tooltip when they mouse over the text.
(There is some discord over the difference between the two tags, but I won't get into that. See Ben Meadowcroft's explanation and Craig Saila's thoughts on usage for more.)
(Additionally, you can use CSS to style your acronyms and abbreviations in a certain way. For instance, this site gives them a light, dotted underline and changes the cursor into an arrow with a question mark. More information on this technique is at Dive Into Accessibility.)
When it comes to online news, this technique would benefit both parties involved: The readers, and the journalists themselves.
Helping the readers
This one's a no-brainer. Acronym and abbreviation definitions clear things up. They make article comprehension easier for folks who have a tough time with alphabet soup, and they stay conveniently out of the way of people who know what the phrases mean already.
Examples:
- Pop-culture references that some readers might not understand: J Lo, Britney, Dickie V
- Geographical locations: Miss., Mass., Minn. (The Web is global. Not everybody cares to memorize the U.S. state abbreviations.)
- Time zones: 5 p.m. EST
- Dates: Tues., Dec. 17. (This may seem silly to you, but put yourself in the shoes of a reader with poor English skills. I, for one, certainly could use help with Spanish abbreviations.)
Helping the journalists
HTML acronyms and abbreviations are a headline writer's dream come true. Even on the Web, editors are concerned about headline length and "fitting" headlines in alloted spaces. (I spent a summer at washingtonpost.com and recall working hard trying to piece together headlines that were short enough for the home page but still made sense.) But the <acronym> tag makes things easy.
No longer should editors mumble, "Is Karzai well-known enough to be referred to in a headline by only his last name?" They can simply use Karzai's last name in the headline and let curious users mouse over the word to find out his full name and title.
No longer should headline writers wonder, "Do most people know what HCFA is?" The people who do, will. The people who don't, will look to see.
This could even be a chance for editors to use more unconventional abbreviations. But I'm not advocating nonsensical abbreviations, such as, well, PNYCTRP, that a reader couldn't possibly figure out. Rather, here's a good rule of thumb: If at least 25 percent of your readers will know what the acronym means, use it. Otherwise, spell it out. Either way, use <acronym> and <abbr>.
Real-world headline examples:
- news.bbc.co.uk: ANC re-elects Mbeki as leader
- Boston Herald: Ted K gives support to Kerry in 2004 race for White House
- sacticket.com: Q&A: Art Rodriguez
A side note: First-mention, or always?
Some say it's only necessary to define an acronym or abbreviation on its first occurrence. I disagree with this. It's no good defining an acronym in the first paragraph of a news story if you're not going to remind people what it is 20 paragraphs later. (That's the semantic-markup version of dropping the ball.)
A reader should not have to scroll a half-dozen paragraphs up a document just to be reminded of what an acronym stands for. Acronym definitions aren't just one-time explanations; they're also reminders.
December 9, 2002, 10:52 AM ET
Trade it on Trodo
I'm back from my moving-time hiatus to bring you a special announcement. (And Lawrence, Kan., is a great town -- thanks to those who've e-mailed.)
I've spent the last few months working on a side project in my dwindling free time. Today, I'm happy to announce it has launched.
Trodo.com is kind of an online bartering site. Basically, you register for a free account and list items you're willing to trade -- CDs, DVDs, books, video games, video tapes or vinyl records. When somebody requests an item from you, you pay for the shipping, send it, and get a credit in that category. Then you can use your credits to request items from other people -- for free.
When you register, you get three free credits. After that, you get a credit for each item you ship successfully. (The credit is awarded after the "buyer" gives you feedback.)
John Rhodes of WebWord had the idea; I was the humble programmer. We both kind of played around with the design (which is incredibly plain at the moment).
Check out the site and let me or John know what you think, or how it can be improved.
December 1, 2002, 2:51 PM ET
Holovaty.com code improvements
In the past few days, I've made a few changes under the hood of this site.
I've given permalink links the rel="bookmark" attribute, as Tantek Çelik has recommended. The rel attribute, according to the W3C, "describes the relationship from the current document to the anchor specified by the href attribute." It's an easy way to make HTML documents more meaningful.
With that in mind, I added rels wherever appropriate (as outlined in the W3C's list of link types):
- Links to this site's home page have
rel="start". - Links to the archive have
rel="contents". - Links to the about page have
rel="help". - Links created via my "smart anchoring system" have
rel="bookmark". - "Previous entry" and "Next entry" links have
rel="prev"andrel="next", respectively.
Also, I employed a CSS negative-margins trick to rearrange weblog headlines. If you're viewing this site in a CSS-compatible browser (such as IE 5+, Mozilla, Netscape 6+, or Opera 6+), you'll notice each blog entry is preceded by a timestamp and a headline. Previously, I had marked up the timestamp as h2 and the headline as h3 -- but I decided the headline should be h2, because that makes more sense semantically and for users of text-only or nonconventional browsers.
So I made the headline h2 and the timestamp h3, but that meant rearranging the HTML so that the timestamp came after the headline -- and I still wanted the timestamp to be displayed above the headline. Thus, I played around with margins for a bit and ended up giving the timestamp a negative top margin, while the headline got a positive top margin to accomodate the timestamp. The result: The timestamp appears above the headline in CSS-compatible browsers (just as it did before), but the headline appears above the timestamp in all other browsers (and in the source). Here's the relevant CSS code:
/* headline */
h2 {
margin: 1.5em 0 0;
}
/* timestamp */
h3 {
margin: -3.9em 0 0;
padding: 0 0 3em;
}
And here's some sample HTML. Note the headline comes before the timestamp:
<h2>Headline here</h2>
<h3>November 28, 2002, 1:12 AM ET</h3>
This is a good example, I think, of separating presentation from semantic meaning.
