• Beginning to think walking to lunch today wasn’t such a hot idea. #
• Dedication: drinking Jamba Juice in the rain. Real dedication: without an umbrella. [Edit: alas, it wasn't me.] #
• Sticker found on a light pole (photo at right) #
• SciFiWire, why build an iPhone app instead of a high-functionality mobile site that would work with iPhone AND Android? #

Social tagging initiative from WaSP to physically tag bad web designers.

Opera hits 106/100 on Acid3 after discovering an Easter egg in the test.

The openSUSE mailing list announced OpenSUSE 4.1, with KDE 4.1, GNOME 4.1, MP41 support, OpenOffice 4.1, XEN 4.1, VirtualBox 4.1, and a 4-in-1 CD install.

Added: The Electronic Frontier Foundation has sent out a newsletter detailing its findings on a Congressional Listening program (apparently they monitor citizens for their opinions—who knew?), plans to move the EFF offices to an armored zeppelin, an NSA-sponsored social networking site (to “allow ordinary Americans to instantly share their private data with the government”), and Homeland Security’s conclusion that Wikipedia is a “Larger Threat Than Terrorism, Dixie Chicks Combined.” Sadly, the newsletter does not appear to be archived on the website.

Added: Virgle, a Virgin/Google joint venture to establish a permanent colony on Mars. Now seeking applicants for Martian pioneers. Takes the Google moon base from 2004 to the next level.

Added: A co-worker pointed out that all of YouTube’s featured videos are Rickrolls today. And it looks like Google is going all-out with some 15 hoaxes today. *whew!*

The Internet Storm Center is keeping a list as well.

The ISC reminds us that IE7 will be pushed out to WSUS next week, which should help get rid of IE6. Yeah, I’d rather more people switched to Firefox or Opera, but I’m at the point where I’d love to be able to stop worrying about IE6’s shortcomings when trying to build sites. IE7’s shortcomings are much easier to work around. (Sorry to keep harping on this!)

The inventor of Norton Antivirus talks about computer security and has some rather interesting ideas on what policies are worth pursuing…and what policies aren’t. Long passwords? Great for protecting a stand-alone machine, but on a 10,000 machine network, they only need to crack one. Patch everything? Not every vulnerability gets exploited. I’ll have to read the Slashdot thread when I have time; that should be really *ahem* interesting.

• Bugs or “missing” features in the new browser (whether incomplete support in the new browser, or proprietary features in the familiar browser).
• Broken code on the website being handled differently.
• Different defaults where behavior isn’t well-defined in the specifications.

A big problem is that when you get into the code, a lot of pages aren’t as specific as the authors think they are. When you write code and test it on one browser, you’re not testing that the code is correct, you’re testing that that browser makes the same assumptions you do.

It’s like ordering pizza.

No, really. Let’s say Internet Explorer specializes in Chicago-style pizza, with a thick, chewy crust. And let’s say Firefox specializes in New York-style pizza, with a thin crust. But each can make the other style of pizza on request.

So you call up Internet Explorer and ask for pizza. They deliver you Chicago pizza, and if that’s what you wanted, you figure your order is fine. If you actually wanted New York style, you make sure that next time, you tell them you want that style of pizza.

But let’s say you like Chicago pizza. You get used to calling up IE and just asking for “pizza,” until one day you’re busy, and ask your roommate to order it. He likes to get his pizza from Firefox, so he calls them up, asks for “pizza,” and you get New York style. That’s not what you wanted. Obviously, Firefox pizza is inferior, because they got the order wrong! Well, no, it’s not, and no, they didn’t. They delivered what they were asked for. If you’d told your roommate to ask for Chicago style, Firefox would have been perfectly happy to deliver that style of pizza.

The moral of the story: always be specific with your code. Make sure it’s asking for what you think it’s asking for (validation helps here). And if something doesn’t do what you expect, make sure you didn’t leave that expectation out of your order.

See also: No, Internet Explorer did not handle it properly

(Expanded from a comment I posted at Mozillazine.)

I believe we have something like 10 – 15 million active desktop users. That is actually quite a lot of people.

If you try to think about it, the place that I’m come from is Iceland. I was born in Iceland, that’s three hundred thousand people – we have a lot more. The place I live is Norway – we have a lot more. Actually if you look at it, the US has about 300 million people that live here, 50 states, about 6 million in each state on average. So which states have people that you would like to ignore?

He goes on to add that Opera Mobile is installed on 40 million mobile phones, with an additional 7 million people actually using Opera Mini. And then there are devices like the Nintendo DS and Wii…

Going by 2005 numbers, only four states have 15 million people or more: California (36M), Texas (23M), New York (19M), and Florida (18M). So take the 10–15M desktop users, the 7M Opera Mini users, and even 10% of the 40M mobile install base, and you’re looking at 21–26 million—the equivalent of the population of Texas.

Put that way, it doesn’t seem so small.

If you’re already supporting Firefox, in most cases the changes to support Opera 9 are minimal. The recently-launched Opera Developer Community has has tools, articles, and other resources to help build cross-platform sites.

Unless, of course, you don’t mind writing off a potential audience the size of Texas.

The fact of the matter is, I’m not worried. I tested my personal sites and the sites I’d built for work months ago, using the IE7 betas, and more recently with RC1. I made a couple of minor changes to some stylesheets, but that was about it.

Why? I’ve been writing standards-based code for years. I validate it from time to time, and I test to make sure it works in the latest versions of Firefox, Opera and Safari as well as IE. So the code was already portable.

Plus, anything new I’ve built since January has been designed with IE7 in mind from the beginning.

Most of the changes were to workarounds for IE6. Either stopping them from running on IE7 (if the bug was fixed), or keeping them running on IE7 (if it was done using a CSS hack).

As a web developer, one of the new features that caught my eye is microsummaries. If the name weren’t already taken, “live bookmarks” would have been the perfect description.

Basically it retrieves info from the bookmarked page and updates the label on your bookmark. Examples given include the current price and remaining time for an auction, or current stock price, or weather data. The page author can describe what chunk of data to use, or you can write an installable “generator” that applies itself to some list of pages.

This is a pretty cool idea: basically a 1-item RSS feed, automatically generated from the current page. (The disadvantage is that the browser retrieves the full page and then extracts the data, whereas an RSS feed is already summarized.) Edit: Apparently it’s also possible to link to a 1-line text document instead.

So, being handed a new tool, I immediately started trying to come up with something to do with it.

And came up more-or-less empty.

There are only two areas on my site that I update regularly: Flash: Those Who Ride the Lightning and this blog—and both are more suited to the list of recent updates that you get with RSS or Atom than the latest-info-only that you get with a microsummary.

It might prove useful for server monitoring, though. Condense the important info from a report (like “No alerts” vs “Server X down!”) and put it on the browser toolbar.

Search engines extract too much of the Web’s value, leaving too little for the websites that actually create the content. Liberation from search dependency is a strategic imperative for both websites and software vendors.

Nice. Because, God knows, you wouldn’t want people to find your site, would you? He rambles on with a whole bunch of garbage about search engine advertising—wait, this is all about advertising? I thought this was supposed to be about searching!—and how, over time, it can take up more and more of your budget until it cancels out the gain you made on that new customer who got there through the ad.

There’s actually a useful bit at the end, though, in which he describes other ways to get people coming to your site—or rather, coming back to your site.

The real goal is to make users come back, and to have them come directly to your site instead of clicking on expensive ads. The ideas above are just a few ways to encourage repeat business. Further in-depth studies of user behaviors and customer needs should reveal many new ways of keeping users loyal.

Of course, no one has ever done that sort of study on how to keep people coming back to a store, or a brand name. Shyeah, right!

This morning I caught the end of an interview on NPR’s Marketplace Morning Report, and the announcer explained that the full version of the interview was available on their website, “dub dub dub dot marketplace dot org.”

It’s a fairly long article about a web browser, and it mentions a few other web browsers including Firefox, Opera and IE. It also mentions websites Amazon.com and del.icio.us. But the only links in the article are to stock quotes and an earlier article.

I understand that it’s Business Week, and I’m not saying they should have linked to every website that was even tangentially mentioned—but you’d think they could have at least linked to the browser company they just profiled! I had to get that link from Slashdot! (Unfortunately, so did everyone else, so I won’t be able to look at the page until tomorrow.)

Edit: Compare the BusinessWeek article to Wired’s take from last month. Even taking into account that they’re written for different audiences, BusinessWeek still looks like a print article that’s been thrown up on the web.

Well, Firefox is nearing 1.1 alpha, and among the new features is real support for outline. I figured I’d set up a test page and see what happened.

I set up two classes, one which applied an outline and one which applied a border, and just tried them on different objects. <p> only looked different in positioning (since border is just inside the edge, and outline is just outside), but <span> illustrated the difference clearly:

The first paragraph has some text with an outline. The second has text with a border. In both cases, the text wraps at the edge of the window, but while the border breaks and picks up again on the next line—as if the span had simply been chopped into pieces—the outline completely encloses each section on its own. This fits with its intended purpose, which is “to make [elements] stand out.”

Opera and Konqueror (and presumably Safari) seem to handle outline already, and display my test page the same way as Firefox 1.1.

Highly professional, that, along with “Our lawyers made us include it and made us use a precious link on our home page to get you here.” Which isn’t to say that I don’t appreciate the sentiment, but the fact that it’s been copied over and over is…interesting to say the least.

It does make me wonder who originated the statement, though.

Peter David: Getting Ink for the Fund – yes, Peter David has gotten a tattoo to raise money for the CBLDF. He follows up: “What have you done for the CBLDF lately?” Well, I’ve plugged it on my website and bought a T-shirt… (Edit: It seems Neil Gaiman just missed this by not answering his phone. Also, Newsarama has posted a follow-up story with photos)

The Great Custom 404 Page Adventure – comparing the sometimes helpful, sometimes hostile, sometimes humorous “file not found” messages at various websites. Update: Ironically, the site’s gone 404 itself…

Indispensable Mac OS X products – ’nuff said.

Pir(l)ouettes – a commentary on Adobe’s history of the ampersand.

ACLU – Pizza – a funny/chilling animation of what might go on if a pizza place could cross-reference your health, library, and banking records while you were on the phone.

After a while I came back to it, and started with very simple buttons like this:

Your browser shows this as:

Valid XHTML XFN Friendly

Here’s the CSS and HTML used for this version:

a.w3c, a.nw3 {font: 9pt Arial, Helvetica, sans-serif; border: 1px #000 solid; padding: 2pt; text-decoration: none;}
a.w3c:link, a.w3c:visited {color: #000; background: #fc6;}
a.w3c:hover, a.w3c:active {background: #fec;}
a.nw3:link, a.nw3:visited {color: #000; background: #adb;}
a.nw3:hover, a.nw3:active {background: #cfe;}

<a class="w3c" href="#">Valid XHTML</a> <a class="nw3" href="#">XFN Friendly</a>

Of course, Netscape 4 had problems with this, because it dislikes putting borders or padding on inline elements — like links. Not only does it push them onto separate lines, but they’re no longer clickable! What I ended up doing was separating out the border and padding rules and putting them in an @media screen section to hide them. So on Netscape 4 it looked like this:

Earlier this month, I found Eric Meyer’s take on the same problem: using CSS to imitate those buttons so that visitors don’t have to download an extra 15 images just for footnotes. He was trying for as exact a match as possible, and the result looks great – in Mozilla, Opera, Safari or Konqueror. But the margins aren’t quite right in IE, and unlike Eric, my site isn’t a showcase of what CSS can do.

I ended up using his idea of putting a single <span> tag inside the link — that’s all you really need to divide it into two regions — and using two classes to simplify using the same styles for different types of buttons. Since I’d already abandoned the idea of an exact match, I didn’t worry about getting the fonts and spacing exactly right, and since I was using these in a horizontal row, I didn’t have to worry about specifying widths. It looked pretty good, at least on MOS:

I still had problems in Internet Explorer, though. It adds the padding together, even though it shouldn’t mess with the line height on an inline element, so it ended up with an extra line of background color around the left section:

Since I wasn’t trying to match exactly, I decided to just remove all the vertical padding, leaving something much narrower than the originals, but much cleaner than what I could get otherwise:

Your browser shows:
W3C Valid XHTML XFN Friendly

<a class="btn w3c" href="#"><span>W3C</span> Valid XHTML</a> <a class="btn fea" href="#"><span>XFN</span> Friendly</a>

a.btn {font: 8pt Arial, Helvetica, sans-serif; padding: 0 .5em 0 0; border: 1px #000 solid; text-decoration: none;}
a.btn span {border-right: 1px solid #000; margin: 0 0.1em 0 0; padding: 0 0.5em;}
a.w3c:link, a.w3c:visited {color: #000; background: #fc6;}
a.w3c:hover, a.w3c:active {background: #fec;}
a.w3c span {background: #fff; color: #06c;}
a.fea:link, a.fea:visited {color: #000; background: #ccc;}
a.fea:hover, a.fea:active {background: #bed;}
a.fea span {background: #093; color: #fff;}

This works well in modern versions of IE, Mozilla, Netscape, Opera, Safari and Konqueror. IE5 gets the colors right, but doesn’t show the borders. Netscape 4, interestingly, doesn’t recognize multiple classes. It thinks “btn w3c” is a single class with a space in the middle, so its freak-out over borders and padding is no longer a problem. It just ends up looking like a normal text link. It’s not great, but at least it works, and at this point that’s all I want for NS4.

There’s one more problem, and that’s one of accessibility. The WAI and Section 508 guidelines both suggest you avoid putting links next to each other with no separation, because a screen reader might not make it clear to a blind web surfer that the links are separate. I haven’t come to a final decision on this one, but what I’ve got on some pages is just separating them with ordinary bullets:

W3C Valid XHTML · XFN Friendly

It’s been tested so far on Mozilla, IE 6, Opera 7, and Konqueror 3.2. It doesn’t use anything more complicated than Fahrner Image Replacement, so it shouldn’t cause too many problems. I’ll try to test it in a bunch of other browsers at work tomorrow.

I consider this a first draft – among other things I figure on adding to the main title banner – but it’s something a bit more distinctive than the out-of-the-box layout we ended up with after the upgrade to 1.0.

Updated Feb. 12 and Feb. 13 to describe testing in more browsers and the interesting saga of tracking down a bug in Internet Explorer 5.0:

Update Feb. 12 @ 10:45. Well, I’ve successfully tested Opera back to 4.0, Mozilla back to 1.0, Netscape back to 6.2 and IE back to 5.5. I still need to check Safari and Mac IE 5, since Katie had turned her computer off by the time I was finished last night. (Gecko browsers are pretty consistent across platforms, so all I really need to check on Mac Mozilla is that the fonts are readable.)

So far, every browser that can be expected to handle the layout has shown it fully or reasonably, except one: IE 5.0 for Windows:

It looks like it’s treating the bottom margin of each post as padding, without moving anything out of the way. (Padding is inside the box, margins are outside.) It should be placing a blank line between the bottom of a post and the next item, but instead it’s extending the box down, causing an overlap with whatever comes next.

This reminds me of the margin problems IE 6 had with my software page layout – but this time IE 6 is fine. It’s only IE 5.0 that’s having problems, and the tweaks I allowed myself time to make haven’t been enough to solve them.

Well, if stats are to be believed, there aren’t too many of you out there still using IE 5.0. I’ll try to figure out a workaround, but for those of you still using IE 5, isn’t it time to think about either upgrading to IE 6 or switching to something better?

Update Feb. 13 @ 16:30. I took a quick look at the resulting HTML code, and suddenly it was obvious: every post on the main page, where comments aren’t visible, had the following code at the end: <div class="storycomment"></div>. It’s perfectly valid, and most browsers just ignored the empty element. If IE 5.0 had just added the blank space, it would have been okay, but it somehow added the space when displaying the surrounding block, but not when figuring out where to put the next block.

Anyway, I moved the <div> tags into the comment loop, so they’re only present when comments are actually shown. The IE 5 display problem is fixed!