I came across this article from the folks at Filament Group last week and have been considering it as an augmentation of my progressive enhancement approach to front-end development.

The idea is that you use JavaScript to manipulate the DOM to test for correct implementation of some advanced CSS stuff (box model, positioning, floats, overflow). If the browser passes, then it gets an enhanced version; if it fails, then it gets a basic version. You can do the version selection via an alternate stylesheet or with the use of ‘enhanced’ class before all the rules for the advanced view (or both).

As you’ll notice in the comments, there is some discussion about browsers that have JavaScript disabled but can still handled advanced CSS. I’m not convinced that disabled JavaScript removes a browser from Grade A status, but you could read the description of Grade A as including support for JavaScript. Regardless, it’s something worth considering, especially as sites morph into applications more and more. Certainly, if you’re using one of the JavaScript frameworks on your site, you’re limiting yourself to the browsers that past these tests since you need a browser with solid understanding of the DOM.

John Resig of jQuery fame posted a response to this method on his site.

Jason Fried gave a rather inspiring talk (to me at least) at SxSW this year about the 10 things they’ve learned at 37Signals. He’s posted one of his slides up on the SVN blog.

The peeps at Nclud came up with a revision to the clearfix method of clearing floats.

.clear {
  display:inline-block; /* or anything that triggers hasLayout in IE */
}
.clear:after {
  clear:both;
  display:block;
  content: ".";
  height:0;
  visibility:hidden;
}

Valid CSS 2.1 and a bit cleaner than the current clearfix method.

I’m off to SxSW on Friday. I went last year and it lived up to all the hype and is hands down the best conference I have ever attended. Rife with folks who love the web and are passionate to make it the best it can be. It’ll be great to catch up with friends and meet new people. BTW I’m packing the sunscreen – no need to repeat last year’s big burn.

Yesterday I noticed that my site was spewing out a couple database errors (who knows how long that’s been happening!). I repaired the tables and seems it’s back to normal.

Do you have CSS that is only used when you have JS enabled? Are you trying to avoid some flickering of pre-JS-ified content? Then put that CSS in its own JavaScript-specific CSS file and write it to your HTML via one of two options.

1. Good ol’ document.write()

   
   <script type="text/javascript">
   //<![CDATA[
   document.write('<link rel="stylesheet" href="js.css" type="text/css" />');
   //]]>
   </script>
   
   

2. Slick new DOM:

   
   <script type="text/javascript">
   //<![CDATA[
   var lnk = document.createElement('link');
   lnk.setAttribute('rel', 'stylesheet');
   lnk.setAttribute('type', 'text/css');
   lnk.setAttribute('href', 'js.css');
   document.getElementsByTagName('head')[0].appendChild(lnk);
   //]]>
   </script>
   
   

Tip to PPK and Tino Zijdel (comment 8).

On a recent project, I came across an interesting bit of behavior from Windows Internet Explorer 6 that I wasn’t expecting. I created the following CSS rule:

input.text,
input[type="text"] {
    border: 1px solid #555; color: #555;
}

I initially created this rule to pass browsers who understand attribute selectors the CSS while at the same time creating a class selector for IE to understand when I added that class to the <input />. (A bit redundant, I know.)

Thing is, IE was ignoring the rule completely. I couldn’t figure out why it was happening. I removed the attribute selector from the rule and IE applied the CSS rule to the <input />.

The more I thought about it, I wondered if IE had trouble with the rule since it encountered an unknown selector last in the chain. What happened if I reversed the order of the selectors?

input[type="text"],
input.text {
    border: 1px solid #555; color: #555;
}

I figured IE would ignore the first selector in the chain and apply the second one. No dice, it still ignored the entire rule.

The lesson here is: If you want to use an attribute selector (or any selector IE doesn’t understand), separate it out as it’s own rule. If you do that, IE will apply the class selector and other browsers will apply the both the class and attribute selector rules.

input.text {
    border: 1px solid #555; color: #555;
}
input[type="text"] {
    border: 1px solid #555; color: #555;
}

Dustin Diaz has embraced nudity full on. First SxSW, now he proposes that we all get naked on April 5.

In the spirit of promoting Web Standards along with good semantic markup and proper hierarchy structures, April 5th will be a day of nakedness for all webmasters to remove their style sheets from their website for one day.

Tip to Steve for this one …

For the past couple months, I’ve been using the Modular CSS and CSS Framework developed by Mike Stenhouse over at Content with Style. I find it to be a rather powerful approach that has served me pretty well so far.

Recently, I came across Alex Walker’s Site Point article about Simple Clearing of Floats. In it, he describes the four techniques used for clearing floated items – The Markup Method (using extra cleared elements), the Aslett/PIE clearfix method, Steve Smith’s Float Nearly Everything, and the use of overflow:auto, as suggested to Alex by Paul O’Brien.

Stenhouse’s CSS Framework employs the use of the Aslett/PIE method. This involves adding class="clearfix" (or whatever you choose for that class) to all containers that have floated items inside. It’s a pretty slick solution that works pretty well for the Framework.

After reading about using overflow:auto, I decided to see what would happen if I used the overflow method instead of the Aslett/PIE method on the CSS Framework. I tested it in the Mac browsers I have (Mac IE, Safari 2, Opera 8, Camino/Firefox/Mozilla/Netscape, and everything more or less worked out as it should have. Two items came up when I tested it:

1. In Mac IE 5.2, overflow:auto adds scrollbars to the elements that have this property. The fix is to add change the overflow property’s value to hidden just for Mac IE. The scrollbars disappear and all is well.
2. Negative tops, absolute positioning and overflow. The CSS Framework puts the navigation inside of the #content block. To position it appropriately, the navigation block is given position:absolute. It appears that if the container has the overflow property, and the navigation is horizontally spanning across the content, then the negative top value does not work appropriately. The navigation sits inside the #content block, atop the content itself. The only fix I’ve found is to add some top padding to the #content block to adjust for this. The navigation does not overlap the content. I also had to make some adjustments to the #header block’s margin-bottom to keep the spacing in tact.

With these two items accounted for, all seems to be working well. Now to test it out on the PCs.

A couple days ago, my feed for Wired resumed updating and pulling in posts. One thing I noticed right off is that NetNewsWire indicated that each entry has an eclosure of an image. I opened up one of them and it revealed itself as a thumbnail to the post. Given that Wired is using RSS 2.0 and could easily include the image inline with the post. I wonder what the reasoning is to include it as an enclosure. I know Wired is involved in the podcast game and the audio/video files for those are included via ‘enclosure’. Just seems odd to put a thumbnail in there.