« February 2005 | Main | April 2005 »

31 March 2005

The Browser the Way You Want It

I'm in awe of Dean Edwards' IE7, considered by many to be the CSS rosetta stone for Microsoft Internet Explorer (MSIE), which also still happens to be the most widely used web browser on the planet. For the long-frustrated web developer the allure is obvious: Link to IE7 from within your standards-friendly page and <BAM!> modern CSS compliance par excellence. What more could you want?

(Glad you asked!)

What's next for IE7? Will it continue to occupy a relatively small (albeit well-respected) niche? Or will it gain enough critical mass to actually level-set the CSS landscape on a broader scale? (You Malcolm Gladwell fans know what I'm talking about.)

Chew On This

First Peter-Paul Koch then, more recently, Dean Edwards put forth that Microsoft can't "get it right" (meaning CSS) because the MSIE rendering engine, Trident, is already sunk. Consulting my Magic 8-Ball® at this very moment, it weighs in with "Outlook not so good." (Wow, what are the odds?)

So while on one hand I'm enthusiastically rooting for Chris Wilson and the entire MSIE7 team to fill the CSS bill (preferably the whole nine yards), between my spidey sense and all the recent disheartening news and speculation on the fate of MSIE7 vis-a-vis CSS, I can't help but have my concerns ... and I know I'm not alone. Meanwhile, there's Dean's IE7 which, despite being in alpha release and having its very own list of caveats, has garnered praise aplenty.

From the web developer's vantage point, IE7 has reached a lofty plateau and limited use, while the king of the browsers continues to dodge (and burn <groan>) the standards-enlightened. All I know is, one way or another, we've got to evolve past partial CSS1/CSS2.1 as the lowest common denominator. So if you consider that Dean has already hit a triple, I say it's time to try knocking that ball clear out of the park. Perhaps if we changed the rules of engagement:

Rewrite IE7 as a Windows Browser Helper Object.

That Dog Don't Hunt

Now before y'all go thin-slicing, I'll step right up and play devil's advocate. Why might a BHO be impractical or a non-starter? (I'll toss in some attempts at rebuttal too. Your mileage may vary.)

  • It's one step forward, two steps back.

    IE7 was a Windows HTML Component (HTC) in a past life. Today it is sitting pretty over in standards-friendly ECMAScript-land. Why go back to Windows-only mode and keep IE7 from extending beyond Windows IE's CSS issues? (Well, are there other browsers out there with CSS issues? No, I mean a monotonically increasing array of really dodgy ones.)

    Actually, I see no good reason not to forge ahead with the ECMAScript "reference version" of IE7. I just think that a BHO version could stand to pack a bigger punch where MSIE is concerned. Besides, I think Dean originally called it IE7 for a reason ... !

  • This could backfire when MSIE7 is released.

    The same can be said for Dean's IE7 too, but I expect all the bases can and will be covered sanely in either case. Also consider that MSIE7 will go through one or more beta releases. There ought to be time to soak things in and plan accordingly.

  • Why spend time helping Microsoft on your dime? Viva la resistance!

    Listen, as thankful as I am for all the other standards-friendly browser alternatives out there, I also remember quite vividly the day I faced reality and finally traded in the "enemy" Netscape Navigator 4 for the "clearly superior" MSIE. It was a welcome breath of fresh air, no question!

    Granted, "that was then, this is now," but facts is facts:

    1. The whole "degree of CSS compliance" issue resonates largely with web developers, not end-users. Even so, if you consider end-users as the ultimate benefactor at the end of the day ... why not be a li'l altruistic?
    2. Kick and scream all you want, but MSIE is still the flavor of the month in my neck of the woods and elsewhere. "It is what it is" ... and if you believe it might be lemon flavored, you might as well try to make some lemonade. That's what Dean did, after all.

    "When life hands you a lemon, say 'Oh yeah, I like lemons. What else you got?'" (Rollins)

  • You can't install a BHO without the user somehow getting involved.

    As ECMAScript, an IE7 "install" is rather stealthy, unless client side scripting happens to be disabled (in which case it's rather dead-in-the-water). By comparison, a BHO is loaded once in MSIE and is "always on" (unless it happens to be disabled, in which case ... you know).

    Here's the rub: Installing a BHO requires some action on the user's part, explicit or otherwise. That's generally considered a drawback. Moreover, since ECMAScript doesn't have the run-of-the-house like a BHO does, any attempt at a surreptitious BHO install is likely a "bad PR move" anyway.

    Speaking of bad PR moves, here's one from the "most damning testimony ever" department:

  • BHOs are the premier spyware playground, bar none.

    My neighbors (who don't even know what BHO stands for) are more than happy to tell their horror stories to anyone within earshot, spreading the meme ever wider. "All BHOs are spyware. Gotta catch 'em all!" Indeed, the Add-on Manager in XP Service Pack 2 (or Spybot - Search & Destroy, BHODemon, etc.) all allow for easy disabling of BHOs.

  • Insert your favorite cautionary tale here.

Right. So ... don't bother? Go home? Are there any positives here? Let's see ...

"Make it Work. Make it Right. Make it Fast."

Dean had his priorities straight from the outset: "IE7 will sacrifice performance in favour of standards," he wrote. Not to rest on his laurels, Dean has also spent plenty of time coaxing every ounce of performance he can get out of the ECMAScript. At some point, however, you can't help but reach a ceiling, a point of diminishing returns. A BHO, being a Windows DLL, affords the opportunity to make IE7 faster, perhaps "stupid-fast." (Kind of like those hyperaccelerated aliens in Star Trek season 3, episode 11. Only without the I Dream of Jeannie wardrobe. Or the buzzing.)

It's not all about the "need for speed" either. For example, there's currently no support in IE7 for print media, stylesheet switching, inline styles or dynamic adjustment to programmatic edits. After reading the IE7 source code at least four times, cover to cover (which only left me more impressed BTW), I'm now thinking a BHO could tackle all of these items quite handily, leading to a more well-rounded offering. Worth a shot, at any rate.

Bottom line: Increased speed, efficiency and efficacy can make a difference, be they perceived or real improvements. Every bit helps.

The Helping Friendly BHO

This wouldn't be the first time BHOs were conceived with good intentions. Case in point: In 2002, IBM created Web Adaptation Technology inspired no doubt by the W3C Web Accessibility Initiative (and written as, of course, a BHO). Among other things, it "enlarges text to enhance the readability of Web pages" and "reduces visual clutter when viewing Web pages." Today, this technology is available as the award-winning WebAdapt2Me. Bravo IBM! (Also of interest: A PowerPoint presentation by Beth Tibbitts from the 2002 XML Conference/Expo explains how the BHO model is leveraged, complete with code examples.)

Of course there are other examples. Adobe Reader, Google Toolbar, Yahoo! Toolbar, most Windows popup/spyware blockers - they all incorporate a BHO somewhere along the way.

There is a major difference to keep in mind, however: IE7 is more of a behind-the-scenes secret agent - out of sight, out of mind. It isn't, excuse the pun, flashy like the others. Not even WebAdapt2Me. After all, why should people expect to install something "just to look at web pages?" It doesn't make all that much sense.

Or does it? Familiar with Greasemonkey for Mozilla Firefox? Turns out Todd Ostermeier has created a version for Internet Explorer, aptly named GreasemonkIE. Not only is it written as a BHO, but, from what I can tell, a Managed BHO (C# and .NET) to boot! Good move, Todd.

Update: As of 9 April 2005, GreasemonkIE is no more. My thanks to Todd for blazing a new trail in the "Useful BHO" category and inspiring others (e.g., me) to do the same.

Bottom line: Respectable precedents have been set. IE7 might do well to follow in their footsteps.

(Not) Up For Adoption

Even if MSIE7 did get up-to-speed with CSS, not everyone is going to be on that boat.

If I understand correctly, the commitment-at-present is for MSIE7 on XP Service Pack 2, but I also know plenty of people who insist on using Windows 2000 (or 98, or 95 ... or even Windows ME). Why? Ostensibly to avoid current spyware, viruses, and other gremlins. They don't even want to be bothered with installing antispyware, the rationale being "It's a lot safer to use an earlier version of Windows." Even if it isn't patched/up-to-date? Even if it has long since been end-of-lifed? "Yes," I'm told, that's a compromise worth making, a risk worth taking.

In other cases, folks have no say in the matter or, for whatever reason, they simply aren't in a position to upgrade. They have to use the Windows version and browser they've been dealt, period. My parents, for example, depend on sites that make extensive use of ActiveX, thus they must use MSIE for those sites. Not to make this a Firefox-vs-MSIE debate (it's not) but I've observed that, even though they have Firefox installed, they tend to keep using MSIE anyway since it's already running and they know it will work for the ActiveX cases. Or, to hear either of them put it: "Some of my web sites break in other browsers. I'll keep it simple and use Internet Explorer."

Meanwhile, web developers are stuck wrestling with the 80/20 rule in reverse: 20% of the time is spent developing for "other browsers" and the remaining 80% is spent "making it work" in MSIE. To be fair, that ratio tends to improve with increased experience and acquired skill. If that's the camp you fall into, consider yourself somewhat fortunate. To this day I still hear stories of neophyte web developers trying to follow the standards using MSIE, only to eventually throw up their hands in exasperation. (Haven't they ever heard of the css-discuss Wiki?)

Be it ECMAScript or a BHO, IE7 would be well-positioned to transcend all of the Operating System hubbub ... but, again, I see the BHO as having more of an edge when it comes to MSIE.

Going Global

Let's suppose an IE7 BHO is just what the doctor ordered. Would that somehow bring it one step closer to the proverbial tipping point and lead to widespread adoption? If done well, I think it could. To borrow Gladwell's terms, I'm hopeful we might find some connectors, mavens or salesmen to help out along the way.

This quote was, up until recently, on the Microsoft FrontPage site: "With so many browsers, consistency is key. If your Web sites don't display well on multiple browsers and at varying screen resolutions, you could be missing out on key audiences." Now that's what I'm talking about!

The Name of the Game

While there has already been plenty of discussion on the name IE7, I'll toss one more name into the ring: Rosetta.

"A little green rosetta. You'll make a muffin betta." (Zappa)

Any Takers?

Enough of my yappin'. Here are some resources ripe for the picking:

Who out there has Visual Studio and some free time on their hands? Obviously Todd has VS ... plus I do too, only it's rather painfully slow on Virtual PC/Mac. Ahh, the price of switching.

Regardless, I'll be happy to pitch in as well. You know how to reach me.

25 March 2005

One Good Turn Deserves Another

In 1999, Broadside Electric (of which I'm a card-carrying member/drummer) released a CD entitled With Teeth. "We promise this is the only record you'll hear this year that has a Croatian dance, an English music hall song and a Bob Dylan cover," we wrote.

Yesterday, I received an email asking me to check out our CD's "Also Viewed" listing at Amazon.com, and I see this:

  • Hand That Feeds ~ Attrition
  • Piano Tribute to Nine Inch Nails ~ Various Artists
  • The Downward Spiral ~ Nine Inch Nails
  • And All That Could Have Been ~ Nine Inch Nails
  • The Downward Spiral ~ Nine Inch Nails
  • Things Falling Apart ~ Nine Inch Nails
  • Disturbed ~ Nine Inch Nails
  • The Fragile ~ Nine Inch Nails

So what's with all the Nine Inch Nails cross-references? It turns out Trent & co. are releasing a new CD in May, entitled ... With Teeth! Amazingly enough, our orders for WT have spiked considerably. (I just hope they know what they're in for.)

Perhaps we should name our next CD The Downward Spiral to return the favor.

19 March 2005

Strangematter

A better-late-than-never welcome to the blogosphere for www.att.com developer extraordinare, Dr. Pepper connoisseur, friend and confidant, Vincent Murphy.

Vincent is the standards Ying to my standards Yang (or perhaps Filo <groan>). Without his tireless collaboration, flashes of insight, mad debugging skills and common-sense observations, www.att.com would not be nearly as far along (if at all) in the web standards realm right now.

His first web-related post arrived this morning too: Sites That Need White Backgrounds. ("But, but, but what about the minty green background?" Ahh, now there's an old chestnut ...)

16 March 2005

An Unexpected Movie Promo

Found while reading to Lex, small caps and all:

The water ran out.
And then I saw the ring!

The Cat in the Hat Comes Back (p. 14, 1958 edition)

(Seven days!)

11 March 2005

Google News, Meet iPod Shuffle

The Google News gang kicks it up another notch. Now you can rearrange categories (I mean sections, think newspaper-speak), turn images on and off, plus <gasp> you can create your own sections. Yay!

Initial observations ...

  • I like that I can directly manipulate the location of each section via drag-and-drop. Nice touch! Haven't yet looked under the hood to see what happens in a no-mouse scenario.

    Your user-agent-of-choice (alright, alright, your browser) may not play nice in terms of visual feedback while rearranging things. For instance, you may find yourself selecting other text as you move sections around. I suspect this can't be helped from Google's end (at least not yet).

    The cursor change (alerting that a section is movable) is welcome, as is a visual indicator of where your section-in-transit will end up before you commit. Well done!

  • Here's where it gets tricky. The customization panel corresponds to the News page itself: two columns of sections (not counting Top Stories). Meanwhile, these sections are summarized as one column in the sidebar, ordered by row, not by column.

    Now, if I drag an existing section (or even a custom one like "AT&T") to the top of the left column, I shift the rest of that column downward, but - stay with me - remember, the sidebar's news sections are ordered by row. This means I've just "shuffled" my sidebar list! That may (or may not) be what you intended. (It certainly wasn't what I intended.)

    What I'd really like to do then is drop a section to the left of an existing one vs. above it. Taking it further, that ever-so-helpful visual indicator could appear not only above a section, but at left, right, or below it, affecting the direction everything else shifts. The danger of course is this could easily make things unnecessarily complex, depending on how it's done. (Perhaps some paper prototyping and a/b testing a la Amazon.com can help out.)

  • Defining a section's keywords is very simple: all terms must match within a news item. Even so, I still find myself wanting a bit more flexibility when it comes to slicing and dicing my news. For example, what if I want to match on "CSS" or "Cascading Style Sheets" within a single section? (If there's already a way to do this and I missed it, by all means speak up.)

All in all, customizations are a welcome enhancement to an already useful service. I'm sure the Google News team is already at work on the next iteration ... if they're not already on their way to SXSWi, that is.

As for me, I will not be able to attend (though I intend to next year). I look forward to reading reports from the field. (Someone shake Malcolm Gladwell's hand for me and thank him, OK? Thanks.)

5 March 2005

Get Yer FQDN On

In a well-meaning effort to keep the IA home fires burning, I've taken another small-but-satisfying step in evolving this site's URI design: Enforcing the use of Fully Qualified Domain Names for all HTTP requests at the Apt.

Here, try a sample link. Go on, try it, you'll like it! (Maybe.)

Previous URI tweaks (or IRI tweaks, choose your poison) included the judicious suppression of file extensions, a.k.a. content negotiation, plus using the entry's creation time instead of the title (or even the entry ID). Bottom line: I prefer to keep the entry URIs completely separate from the CMS and any server-side technologies. From what I can tell, I'm about as fussy as Drew McLellan when it comes to this stuff.

More adjustments are surely afoot. F'rinstance, I find the /controller/method/options URI model used by Rails rather appealing (echoes of Zope!). This model - not to mention Rails itself - may yet find a home here.

Right - meanwhile, back to the domain name thingy. "It ain't done with smoke and mirrors." Those with Apache and mod_rewrite can simply add the following to .htaccess in the document root.

Options +FollowSymlinks
rewriteEngine on
rewriteBase /
rewriteCond %{HTTP_HOST} !^www\.joesapt\.net$ [NC]
rewriteRule ^(.*) http://www.joesapt.net/$1 [L,R=301]

Replace joesapt.net with one of your own, natch. It goes without saying, please please please test on your end to verify it works as expected. If it doesn't, and you're not sure why, feel free to contact me and I'll do my best to help out. There are plenty of subtleties with mod_rewrite and you may have rewrite rules or server settings in place that don't play nice with the above. (They don't call it the "Swiss Army Knife of URL Manipulation" for nothing.)

It's nothing new, really it isn't, yet a lot of sites do not employ this technique (including another one under my purview that shall go unnamed ... but that's another story, altogether*). You could likely argue that it's all unnecessary, sure, but hey - that's just me.

Who knows? You may be so inclined as to take the opposite tack, removing the www. It's your call. Either way, you'll wind up with more consistent linkage to and fro. Isn't that swell?

Kreskin sez: If you paused to deadpan "but that's another story" to yourself while reading that parenthetical remark, uhhhh, I bet you must be a Zucker/Abrahams/Zucker fan! Did I get it right? Huh? Did I? I guessed it, right? Amazing!

1 March 2005

Getting MT-Mail-Entry 2.0 working in MT 3.1x

Several MT enthusiasts are reporting that Stepan Riha's MT-Mail-Entry 2.0 throws an error as of MT 3.1 on up;

Can't call method "param" on an undefined value at mt-mail-entry.cgi line 54

Here's a quick fix.

Short and sweet, this one is (and Yoda I am not by a longshot - ahem). Replace the line that reads:

my $q = $app->{query};

with:

my $q = CGI->new;

It should now work! Since I saw reports of this working pre-3.1, I'm guessing that the 2.6x version of MT provided access to the CGI query via MT::App. If so, that's either no longer true or perhaps said access has moved elsewhere within MT::App. I didn't catch any notable clues while debugging the CGI, but no matter - this ought to do the trick. Enjoy ...

Or rather, I will enjoy ... once I nail down a reasonable game plan to keep it from being flagrantly abused. (If anyone has suggestions, by all means ... and yes, I've already changed the name of the CGI. Heh-heh.)