Easy Reader

Yeah, I’m weighing into the debate on the ALA redesign. I have to say I agree with Jon and Jeremy regarding the fixed 1024px width. My little 2¢ to add to this discussion is that I think more designers should consider the wonderous world of CSS switching based on browser width (see Rammstein or the slightly better implementation on Drink-drive-lose.com’s Ad Challenge). Using this technique, users can view your site at their most comfortable screen resolution and you can still have a nicely designed page for them (fixed or liquid… or both). Can you say zoom layouts? I knew you could.

I finally got around to reading Chris Wilson’s post about standards support in IE7 and I have to admit I am more than a little giddy. Working for an ad agency, most clients (and the majority of my coworkers) have not gotten the whole Web Standards thing, mostly because they only use IE. I can’t express how much relief I feel that IE7 is going to fall in line with most of the other browsers out there with regard to standards support.

Improvements of particular note are alpha transparency in PNGs and support for <abbr>s. When it comes to CSS, a whole host of bugs/issues have been fixed (mostly culled from Quirksmode and Position is Everything). I am left with two nagging questions, however:

1. Will the * HTML CSS hack still be supported in IE7 or will that be phased out so * HTML only affects IE6 and below?
2. Has the DOM interface been upgraded so we can run more powerful scripts in IE7?

Overall, I think this is a huge step forward. I have to hand it to Chris, the IE team and WaSP’s Microsoft Corporation Task Force for making this all a reality. A very hearty thank you goes out to all of you, you made my year.

UPDATE: A recent blog entry on IE Blog has informed us that the * HTML selector will not be supported by IE7 in “strict” mode.

I was browsing the popular links on del.icio.us today and stumbled onto Nifty Corners and (via that page) More Nifty Corners. I have to say that I am incredibly impressed with the scripting, but I fear there is something wrong with this picture.

Lately, there have been some border wars over the CSS :hover pseudo-class and its forays into the behavior layer. Sure, it’s easier to have CSS do the work sometimes, but that doesn’t make it right. Frankly, I agree with the concept that behavior should be separated from presentation, just as presentation should be separated from content (which is why I use JavaScript to open and close the faux-<select> in my <select> Something New series).

I am also a big believer in clean, semantic markup, so I become concerned when anyone is adding superfluous code to the document to force a design issue. I know some might say I live in a glass house, but when I see someone putting code like this

<div id="container">
  <b class="rtop">
    <b class="r1"></b> <b class="r2"></b>
    <b class="r3"></b> <b class="r4"></b>
  </b>
  <!--content goes here -->
  <b class="rbottom">
    <b class="r4"></b> <b class="r3"></b>
    <b class="r2"></b> <b class="r1"></b>
  </b>
</div>

into their document (even if it is via the DOM), I begin to shudder. Maybe it’s the nagging purist in me, but that just seems wrong.

Are we falling into the old patterns again, forcing design issues through hacky markup? Does the use of non-semantic markup (taking a page from Eric, no doubt) make it OK? Does the fact that it’s inserted via the DOM make it any more valid? Where do we draw the line?

I don’t have the answer, but I think we need to have the conversation.