by Kyle Weems 30.April 2008 14:07
I had the (mis)fortune to watch the 1983 fantasy 'classic' Krull yesterday. With the amount of laser beams and white-clad troopers in the film, it feels like someone put Sleeping Beauty with Star Wars in a blender, then had Lewis Carrol write the dialogue. I enjoyed it immensely, but then, I am apparently sick in the head.
The premise goes as follows (I swear there's a point to this): Prince Colwyn goes to marry the princess of an opposing kingdom so their lands can unite to defeat 'the Slayers', an invading army from space. During the wedding everyone but him is killed, and he's rescued by an old man that I'll call Obi Wan Kenobi's Doppleganger (or OWKD for short). OWKD tells Colwyn that he needs a mystic weapon called "the Glaive" to defeat "the Beast" that leads the Slayers and rescue the princess. So Colwyn proceeds to climb tall mountains, stick his hand in lava, recruit criminals, get a couple of seers and OWKD killed (and a cyclops) and so forth before finally confronting el Beasto in it's asteroid/fortress lair. Finally when the time comes for him to defeat the big baddy, he manages to wound and knock it down with his Glaive (always capitalized in speech) only to have the beast get back up and proceed to look like a bad acid trip. All would be lost, but at the last moment he and the princess realize (with little clues as to how) that the way to beat the Beast is their true love, which manifests in this case as a magic flame that was part of their wedding ceremony. Colwyn then proceeds to kill the Beast, destroy the fortress, and wipe out the Slayers with the magical love flames.
*deep breath*
So what was the point? The point was that OWKD, experienced savant and mystery man, totally misled Colwyn into an unneeded super journey by telling him that the Glaive was needed to kill the Beast, when in fact all he needed was his magical wedding love flame.
I experienced a much less epic version of this recently when working on a client's site. (Ok, by less epic I mean that I had no troops following me, no magic weapon, no cyclops friends, and a distinct lack of enemy fortresses, so the comparison may be a bit strained.) In particular, the client has a list of files on various pages on the site, and the list was to be decorated by icons depicting the file types used. This feature was requested late in the stage of the project, so the code responsible for generating the list didn't provide any classes on the anchor tags based on the type of files linked to.
Ever since I attended a workshop at WDN08 by Andy Clarke I've been drooling more and more over CSS3 attribute selectors, and thought this would be the perfect solution.
Attribute selectors are conditional modifiers that can be added to CSS selectors to make them apply to an element that matches certain values in certain attributes. The notations vary depending on the type of attribute selector being used, but they range from e[attribute] (which matches an element e with the attribute listed in it) to the more commonly used e[attribute="value"] (which matches e only if it's attribute has the value contained in it) to the awesome CSS3 attribute selectors like e[attribute*="value"] (which will match e if the value appears anywhere within the attribute).
In the case of this particular project, I needed a different icon for all items linking to .PDF files versus an icon for any other file type. So the obvious solution was to insert selectors to the effect of a[href$=".PDF"] for the pdf files (it matches any anchors that have an href that end in .PDF] that would override the icon style for the generic a. My glee came grinding to a halt when I encountered the following in the SitePoint CSS Reference that I was using as a source: "Internet Explorer 7
doesn’t support the partial matching of attribute values." with a little visual graph indicating that no version of IE supported CSS3 attribute selectors yet.
Curses! Once again, the evil, scaled beast that is Internet Explorer (also known as Darimikanius the Devourer) has reared its head and sent good design standards running.
So bemoaning the unfairness of it all, I spent an hour polishing my rusty JavaScript skills and plugged a script into the site that would add a class to the anchors if their href attributes linked to a pdf file.
Was it as hideous as fighting Slayers in a swamp next to a cyclops? No. But time equals money, and as it turned out, my mentor was as incorrect as OWKD was to Colwyn.
You see, after I'd finished up that project, I started working on a generic JavaScript that would provide CSS3 attribute selector support for IE7, thereby allowing me to use those selectors in future projects. Partway through the coding process, I put together a test page that I'd hang the script on to test it, and loaded it up in my browsers prior to adding the script to make sure everything was looking proper.
To my shock and horror (or relieved surprise, I'm not sure which) IE7 was rendering the selectors all on it's own.
SitePoint had lied to me!
Well, perhaps it merely made a mistake. But after getting over the sheer waste of time I'd spent on the project, I found it funny how accustomed we are as web developers to IE's standards-compliance issues that we're willing to accept that it doesn't support a feature without first testing it ourselves.
Consider my lesson learned.
To prove I'm not insane, check out the following test page in IE. Like all the other browsers, it's properly using all the attribute selectors, including the CSS3 ones. So I could have saved the client an hour instead of inventing an unneeded script.
There is a catch (as always). IE6 doesn't support any attribute selectors at all, including the CSS2 ones. Don't take my word for it, load up that test page in IE6. This is unfortunate, but it isn't precisely a disaster. I personally think that it's ok to have a different appearance for your page in IE6, as getting a site identical on all browsers is a holy grail that'll never be acquired. But if the need arises for as similar an experience is possible, it turns out that someone has done all the hard work of making IE6 work properly. I'm speaking, of course, of Dean Edwards. His IE7 script has undergone a lot of upgrades recently, but it still does all the wonderful things it's done in the past. I've added the script into a second test page, which if you view in IE6 will render properly.
So save yourself some grief and check how a style works before taking IE's poor performance for granted.
Oh, and someone get SitePoint to update their CSS3 attribute selectors page.