Posts in the Tech Category

Matt Mullenweg announced Akismet yesterday.  It’s a comment-spam defense system for WordPress, and I’ve been using it for a few weeks now.  (This is why Gatekeeper disappeared from the site near the beginning of the month.)  It isn’t perfect, but it’s darned close, and it’s been getting better as time has progressed.  That’s one of the promised features: the longer it’s used and the more people who use it, the better it gets.

I don’t pretend to understand all the details of Akismet’s workings, although I have a fairly good idea of how it works.  I have some concerns, mostly in that it seems like spammers could poison the well by injecting tons of false “not spam” data into the service in order to get their messages through.  I also worry about attacks on the service itself.

Furthermore, I have to say it’s a bit frustrating that you have to have a wordpress.com API key, which means you have to have a wordpress.com account, which means it’s not a one-stop plug-and-play solution.  (Especially since getting an account is, currently, an invitation-only sort of thing.)  On the other hand, having to have an account probably confers some control advantages—if an account is found to be consistently marking things as “not spam” when everyone else is marking them spam, it can be kicked out of the service.

Some have raised privacy concerns because every comment submitted to your site gets analyzed by the Akismet service.  This doesn’t bother me, but it might some.

Overall, I’ve been pretty happy with Akismet.  It has let through less spam than Gatekeeper did in the weeks before I disabled it and all my other anti-spam measures to test out Akismet.  You’d think a Gatekeeper setup wouldn’t let anything through, but you’d be wrong; I assume there was a hole in my PHP.  Akismet may not be the end-all solution—after all, if it becomes effective enough, the spammers will have major incentives to defeat it, and will most likely find ways to do so—but it seems to be working very well for now.

• Akismet was published on Thursday, October 27th, 2005.
• It was assigned to the WordPress category.
• There have been thirteen replies.

I noticed this morning, after the power finally came back on, that the graphic next to the information on the Carson Workshops home page about the CSS/XHTML workshop I’m doing in a couple of weeks has a “LAST FEW” banner over it, so it looks like those seats are going fast as well.  If you were interested in that one but hadn’t yet gotten around to registering, now might be a good time.

• Selling Out Again was published on Thursday, October 20th, 2005.
• It was assigned to the (X)HTML, CSS, and Speaking categories.
• There has been one reply.

To follow up on what I said recently, there’s another major reason to remain un-stressed about the impending release of IE7 and the use of CSS hacks.  If you read over the list of things that have been fixed, they read like a who’s who of CSS hacks—and a who’s who of the reasons we use most CSS hacks in the first place.

How is that the ticket to a stress-free existence?  I’ll give you an example.  One IE bug I deal with a lot is the doubled-margin float bug.  So I’ll write something like this:

#main {float: left; width: 30em; margin-left: 150px;}
* html #main {margin-left: 75px;}

I’ve halved the margin value in the “IE/Win only” line, which is the second one; that’s the CSS hack part of the duo.  By taking this approach, the layout is consistent between IE/Win and every other modern browser out there.

Okay, so here comes IE7, which the team says has a fixed CSS parser so the Tan hack (which is what I used) isn’t recognized.  That means IE7 completely skips the second line, the one with the hack.  But IE7 has also fixed the double-margin bug on floats.  So the hack rule is completely ignored by IE7, and it acts like other browsers when reading the first.  It’s like it was Firefox or something.  Meanwhile, any IE6 users out there get a consistent experience thanks to the Tan hack line, which it still recognizes.

So why aren’t I proclaiming that there’s absolutely nothing to worry about, as opposed to declaring my intent to stand pat?  Because the promised fixes are just that: promises.  I have no doubt as to the IE team’s deep desire to get these fixes shipped.  They may, however, find themselves overruled by other factors on one or more fixes.  Perhaps a given fix breaks the layout of eBay, or interacts badly with a particular version of Windows.  Simply put, forces beyond their control might lead to a shipping browser that doesn’t fix everything they want to fix.

That’s a big part of why I said I wasn’t going to make any moves until we have a working release in hand.  There’s absolutely no sense in rewriting all our style sheets to remove hacks—at least, there’s no sense right now.  We’d be trying to author against a moving, distant, and phantom target.  That’s a recipe for frustration.

In general, if the planned fixes do come through, then as far as site breakage, the advent of IE7 will be practically a non-event in the standards-oriented design community.  Assuming those  fixes are released, we’ll honestly have next to nothing to do.  Yes, there will be examples here and there of sites doing funky stuff and experiencing problems, as with Slashdot.  Those problem sites will be identified and fixed one way or another—maybe new hacks, maybe conditional comments, maybe reformulations of markup and CSS.  The same basic thing happened when IE6 came out, and I suspect we’ll have less upheaval with IE7 than with IE6—and IE6 was pretty small stuff, site-breakage-wise.

Note that I suspect.  I don’t know.  Nobody can know until the IE team releases a version with the fixes included.  When that happens, then we’ll start figuring out which way to jump.  Or I will, at any rate.  If anyone out there wants to do a little pointless panicking ahead of time, well, be my guest.

• To Hack With It was published on Tuesday, October 18th, 2005.
• It was assigned to the Browsers and CSS categories.
• There have been twenty-four replies.

As noted on the WaSP site, the IE team is asking developers to clean up their CSS hacks because they’re causing sites to break in IE7 builds.

I have to admit that this call elicited an arid little chuckle from me, because it’s a case of chickens coming home to more than one roost.  There’s the fact that bugs in older versions of IE led us to use hacks, and so they’re making life harder for the IE team.  And then there’s the fact that the use of hacks is an inherently risky and fragile process, so the release of IE7 will make life harder for those who used them.  No smug self-superiority should be read into that second point, by the way: I quite firmly include myself in that crowd.

So—now what?  Personally, I’m not going to make a move until an IE7 beta with new CSS behavior is released.  Why change hacks just to have to hack more?  Put another way, if the ground is going to start shifting, there isn’t much sense in trying to guess how.  Wait until it does, and then adjust your footing.

Still, it might pay to consider ways to cope once the ground shifts.  This leads to something I’ve been pondering for a bit, and now’s a good time to bring it up.  When IE7 (the browser) comes out, it will make IE7 (the script) even more useful than it is now.

Here’s why: all the stuff that IE7 (the script) does, IE7 (the browser) is supposed to do as well.  That is to say, the script can bring IE6 up to par with IE7 the day IE7 is released.  See where I’m headed with this?  Instead of being chained to the fat tail of IE6 installs while being unable to use parser hacks in IE7, we can clear away the hacks and have IE6 and IE7 act basically the same.

They will of course not act exactly the same, and yes, there are drawbacks.  IE6 users will have to download the extra script, and those with JavaScript disabled will have problems.  Not every site will be able to accept those costs—but I’d wager the vast majority will.

In the main, it will be a lot less painful to clear out the hacks with IE7 (the script) available than without it.  A lot.

Oh, and before people start exhorting the use of conditional comments instead, it’s still too soon to know how good an idea that might be.  Doubtless they’ll come into play, but exactly how is completely unpredictable until we know what IE7 actually does.  Perhaps we’ll start using conditionals around the call to IE7 (the script).  Perhaps not.  Time will tell.

As I said before, it’s too soon to know which hacks to clear away or how to rework our code, but thanks to Dean Edwards’ efforts, I’m feeling a distinct lack of stress over the impending shifts.

• IE7 and IE7 was published on Monday, October 17th, 2005.
• It was assigned to the Browsers and CSS categories.
• There have been thirty-six replies.

Over at UIE‘s Brain Sparks, the brilliant and lovely Christine Perfetti talked recently about the 7-11 Milk test, and how web sites fail this test 70% of the time.

I’m glad to see that they intend to do more research on the topic, because I think there’s a lot more to the story than just buying milk, and I hope that’s factored into the future research.  Buying on web sites, to me, is not really a 7-11 milk purchase.  It’s more like trying to buy a wood screw for a specific purpose at Home Depot when I’m used to buying them at a corner market.

See, 7-11’s are all pretty much the same.  If you’ve been in one, you know where to find the milk.  Even if the one you’re in is laid out differently than you expect, the conventions are all pretty much the same.  Even if you’ve never been in one before, it won’t take long to get the lay of the land and find the milk.

But walk into a Home Depot and you’re immediately overwhelmed.  I want to find this one thing that’s so tiny compared to what’s in front of me!  There’s an immediate low-level feeling of futility.  Furthermore, any expectations I might have from my local market experience are useless, or even counterproductive.  And even better is when I ask for help and get sent to the wrong place, as has happened to me many a time in Home Depot.

Once I do find the wood screws, then I’m presented with a wide range of choices, and I have to determine which one is best.  Odds are that there won’t be anyone there able to help me make a decision, either; I’m on my own to try to figure out which is the best wood screw for my needs.  The feeling of futility returns.  If I’m not particularly invested in buying this wood screw, I might just give up at this point: faced with too many choices, most of which are going to be wrong, I might decide to make no choice at all.

Furthermore, it’s much easier to bail out of the buying process on a web site.  If I’ve gone to the time and effort of finding and visiting a Home Depot, I’ve invested something in achieving an outcome.  With a web site, I can just come back later.

You can probably draw analogies between the experience I just described and shopping on a web site: the overwhelming home page, the search to find something resembling I want, the misleading cues, the array of choices once I get there.  If web sites were as consistent as 7-11 stores, and online purchases were as simple as “I need milk”, then yes, a 70% failure rate would be abominable—almost unimaginable.  Neither is the case, though.

Mind you, this is not to suggest we should shrug our shoulders and accept this state of affairs.  I think that UIE has an opportunity here to identify the chokepoints (and I use that word on purpose) in the shopping process.  Done correctly, what they find could be applicable in physical space as well as on web sites.

• Milk vs. Wood Screws was published on Monday, September 26th, 2005.
• It was assigned to the Web category.
• There have been eleven replies.

With the Redesign Watch back up and running, the most recent entry is Slashdot, the venerable geek portal so infamous for its ability to kill web servers with a single link that the site’s name is a verb meaning “to bring a server grinding to a halt”.

I was asked in a comment:

What’s your feeling on slashdot being HTML 4.01 (and slightly failing validation) VS XHTML 1.0?

My feeling is good.  Why?  Let’s take the second part first.

When it comes to HTML versus XHTML, I just do not care.  Sure, sure, people will tell you that XHTML is XML so it’s more transformable or something.  That’s a very good argument when the XHTML is well-formed and valid.  It’s also a very good argument for using HTML when it’s well-formed and valid.  Conversely, neither HTML nor XHTML is easily transformed when ill-formed and invalid.  This is an experiential point of view, too: I’ve written XSLT (which is itself so tortuous and ugly that it almost by definition cannot be called well-formed) to transform both HTML and XHTML, and the effort is pretty much the same each way—assuming well-formed, valid markup.

So as far as I’m concerned, there’s really no major practical difference between HTML and XHTML.  There are plenty of minor practical differences, like having to throw trailing slashes on all your empty elements in XHTML and needing some namespace information.  Some people will tell you the whole MIME-type thing is a major practical concern, but I’m just not that much of a purist.  Take that for whatever it’s worth.

I mean, imagine a world where Slashdot had used XHTML instead of HTML, and was failing validation.  How would that be any better or worse than things are now?

Okay, so that’s the second part.  The first part, the failure to validate, is not something I can get too terribly upset about.  Slashdot, as a site that accepts ads, is going to get horrible markup shoved into its pages.  That’s just the way it is.  If you want major sites to be perfectly valid, then in all honesty advertisers are the place to start.  So they’re already operating with a major handicap there.

Even if we were to ride our high horses along a very hard line and say that ads are just no excuse, I’d be hard-pressed to fault the job they’ve done.  For example, I ran a check on the Slashdot home page.  Out of 1,262 lines of code, there were exactly four validation errors, and that’s using HTML 4.01 Strict—you’ll note they bypassed Transitional, which only increases my respect.  Three of the errors revolved around an image in a noscript element, and the last was due to the presence of a language attribute on a script element—something they can fix in fifteen seconds, once it gets to the top of the to-do list.

You know what?  I’d be ecstatic to have that low a failure rate when launching the markover of an incredibly complex site like Slashdot.  Think about all the content they have to manage, stitch together, and offer up.  Four errors out of all that dynamically assembled markup?  I say somebody should organize them a parade for doing such a good job, and showing that any site can make use of and benefit from standards.

I’m also really looking forward to the restyling of Slashdot through user-created style sheets, and the Greasemonkey enhancements built on top of this new structure.  If there’s a site whose readers are inherently primed to script the holy bejeezus out of it, that would be the one.

Would I be happier if they’d managed to achieve total validation?  Of course.  In the meantime, though, I’m going to be very nearly as happy for what they’ve accomplished, and also for the simple fact of it being another major site that’s taken a big step forward.  Progress is always a cause for celebration in my world.

• Slashdot’s Validity was published on Sunday, September 25th, 2005.
• It was assigned to the (X)HTML, Redesign, and Standards categories.
• There have been eighteen replies.

Those of you in the Boston area might be interested in a talk I’m giving at the Macromedia Boston User Group meeting on Wednesday, 12 October 2005:

From Comp To Code: Pulling A List Apart Together

You’re handed a graphic comp file and told to make it into a living, breathing web page.  Now what?  How do you figure out what approach to take, which techniques to use, and what kinds of markup will go into the final page?  Eric gives us a fast-paced tour of his decision-making process as he tackled the new design for A List Apart– how he analyzed the requirements, the questions he had to ask, the trade-offs he made, and the reasons behind his decisions.

If you’re interested, then please join us from 7:00pm – 9:00pm in E51-151 (Tang Center) on the MIT campus.  According to the meeting organizer, arriving early is recommended.

If you do decide to drop by, I’m sorry to say that you won’t be the first to hear this presentation: that honor, if we can call it that, will go to the attendees of Web Essentials 05.  On the other hand, you’ll be getting a more detailed version of the talk, since at WE05 I only have 45 minutes.

On the third hand, could it be that both groups will be getting a sneak preview of just one of the topics to be discussed as part of An Event Apart Philadelphia?

Maybe.

• MMBUG Talk was published on Saturday, September 24th, 2005.
• It was assigned to the Redesign and Speaking categories.
• There have been seven replies.

After an extended hiatus, the Redesign Watch is back.  I’m celebrating its return with eight new entries, including the very recently announced HTML+CSS reworking of Slashdot.  I wonder how their work compares to the third-party job that Daniel Frommelt did a couple of years ago.

Since only the most recent five redesigns are shown on the home page, you’ll have to dig into the archive if you want to see all the new stuff—from Everything Tori on forward—or you could just subscribe to the RSS 2.0 feed.  You can find it and other meyerweb feeds on the Feeds page.  (Go figure!)

• Back On Watch was published on Thursday, September 22nd, 2005.
• It was assigned to the CSS and Redesign categories.
• There have been eleven replies.