No Mod Required

This is one of my favorites so far. I love the simplicity of it and the colors are like ta-dow!

Next up? I and J.

The Blob - Criterion Collection
Steve McQueen!

McQueen was 28 when he played a high school student in this film. He looked like he was at least 38.

Other than that, what a great film this is. 50s horror and Sci-Fi are the bee's knees and, of course, Steve McQueen kicks ass.

That's all that really needs to be said about that…

Research-Based Web Design & Usability Guidelines. Want a concise encapsulation of issues pertaining to usability and web design? Look no further than this (free) book from usability.gov. This is a thought provoking, easy-to-digest read that should be required reading for basically anyone that works on the web.

For what it's worth, I did a redesign of my home page based on some of the guidelines and after a couple of weeks I've seen real improvement in home page performance. I'll post a case study in a few weeks, once I have a larger data set.

If you're using Flash and you want the best possible coverage (meaning it works with users who don't have JS turned on) while still using something like SWFObject where possible to get around the "click here to activate and use this control" ActiveX message in Internet Explorer, then take a look at the ridiculous pattern below.

Warning- not for the squeamish…

Here's the HTML:

<!--[if IE]>
   <noscript> 
   <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=7,0,19,0" width="1004" height="281">
      <param name="movie" value="_assets/flash/homepage.swf" />
      <param name="quality" value="high" />
      <embed src="_assets/flash/homepage.swf" quality="high" pluginspage="http://www.macromedia.com/go/getflashplayer" type="application/x-shockwave-flash" width="1004" height="281"></embed>
</object>
</noscript>

<![endif]–>
<!–[if !IE]> <–>
   <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=7,0,19,0" width="1004" height="281">
      <param name="movie" value="_assets/flash/homepage.swf" />
      <param name="quality" value="high" />
      <embed src="_assets/flash/homepage.swf" quality="high" pluginspage="http://www.macromedia.com/go/getflashplayer" type="application/x-shockwave-flash" width="1004" height="281"></embed>
   </object>
<!–> <![endif]–>

Here's the SWFObject script served to Internet Explorer and ONLY Internet Explorer

<!--[if IE]>
<script src="_assets/js/swfobject.js" type="text/javascript"></script>
<![endif]–>

And here's the SWFObject call:

        //use conditional compilation to hide this call from non-IE browsers
	/*@cc_on @*/
        /*@if (@_win32)
	if ($("home")){
		var so = new SWFObject("_assets/flash/homepage.swf", "mymovie", "1004″, "281″, "8″, "#336699″);
	   	so.addParam("wmode", "transparent");
	   	so.write("messaging");
	}
	/*@end @*/

Before I go further, let me just say I'm counting the days until I can just dump a SWF into the page and be done with it. I hate all of these script based machinations to get a SWF out to the browser. This is code overhead that really bugs me…

Anyway, here's the HTML logic.

• We use Microsoft's conditional comments to show/hide content
• In the "This is IE" block we use a noscript tag to present a traditional embed to IE users who might have JS turned off.
• Every other IE user with JS turned on will see the SWF embedded by SWFObject so no "click to activate and use this control" will be visible to the user. Since the majority of people on the web use IE and the majority of them surf with JS turned on, most users will fall into this category.
• Then, in the "This is not IE" block, we just embed the Flash the old school way. Since the Eolas suit doesn't come into play with other browsers, embedding the SWF the old way is fine (at least in terms of the "click here…" nonsense.) As an additional benefit there's no concern over whether or not the user has JavaScript turned on. JavaScript or no, the only issue is whether or not they have the plugin. Whereas with SWFObject there's a possibility (however slim) that a user could have the Flash plugin installed but be surfing with JavaScript disabled. As I mentioned, this is for the best possible coverage… Also, if they don't have the plugin they get the "download this plugin" notification. I head reports that that wasn't happening with SWFObject running* so getting that to work properly is definitely a bonus. It was actually that bug report that got me into this whole mess

As for how it works technically, the following

<!--[if IE]>

Is read by IE as a test (if the browser is Internet Explorer.) Every other browser reads it as an open comment. Since it's an open comment everything up until the close comment (<![endif]–>) will be ignored by non-IE browsers. IE, on the other hand will go ahead and process that markup normally since it recognizes that pattern as a conditional and its test will evaluate to true.

As a note, I don't like using this stuff all over the place**, but in a situation like this conditional comments are a great option to have.

On the flip side All other browsers read this pattern:

<!–[if !IE]> <–>

As a completed comment, opened and closed on the same line. Therefore everything that follows is rendered normally by Firefox, safari and all the rest. IE, on the other hand, reads it as the beginning of a "If the browser is NOT IE" conditional. Since that resolves to false, everything down to the end of the conditional endif (<!–> <![endif]–>) is ignored by Internet Explorer. That allows us to go back to the future and embed flash in the old school way for everything but IE.

Oh the pain.

Still, if you absolutely need the best possible coverage and want to use SWFObject, this is a way to go. Is it the best? Probably not, since it's horrifyingly hack-y and won't validate. But it might be useful for someone out there…

*and I could figure out how to make it happen…
**I mostly use it to attach IE specific style sheets. For those of you keeping track, that looks like this:

<!--[if gte IE 5.5]>
<![if lt IE 7]>
<link rel="STYLESHEET" type="text/css" href="_assets/styles/ie6.css" />
<![endif]>
<![if gte IE 7]>
<link rel="STYLESHEET" type="text/css" href="_assets/styles/ie7.css" />
<![endif]>
<![endif]–>

Why? For fun, of course- and to expand on a point I made today at work…

Some background- I'm working with a new guy who is not so savvy to modern HTML/CSS layout techniques and today, while talking to him about some potential techniques he might use for an upcoming site, I remarked - "With CSS you can make practically any element do whatever you need it to do, so don't always assume you need to wrap things in a DIV* to make a layout work." The point related to the dangers of DIV-itis and my desire** to pare down markup to its absolute (meaningful) minimum. But it also illustrates a basic idea that, once fully understood, opens up all sorts of options for problem-solving.

So, anyway, chewing on the exchange on my way home from work I was struck with the idea of doing a simple three column layout using nothing but an Unordered List. My original comment was about a UL used as a menu and tweaking it to behave like a bunch of divs (which was his original idea for the menu) or something, so I thought it might be interesting to go all out use a UL for the entire layout, tweaking the LIs in a whole bunch of different ways to suit my needs. If that doesn't illustrate my point, nothing will.

And, yeah. I'm sure a bunch of people have already done this. It was still interesting for me to do so it was well worth the effort no matter how many people out there are yawning in my general direction.

And here it is, in all it's List-y glory- A Three Column CSS Layout Using Just an Unordered List

Here's the pertinent markup

<ul id="container">
<li id="header">header</li>
<li id="content">
<h1>Content</h1>
<p>Lorem ipsum dolor sit amet… Pellentesque in erat.</p>
</li>
<li id="right-sidebar">right sidebar</li>
<li id="left-sidebar">left sidebar</li>
<li id="footer">footer</li>
</ul>

And here's the CSS

* {
	margin:0;
	padding:0;
}
li {
	list-style-type:none;
}
#container {
	margin: auto;
	width: 825px;
	border: thin solid #FF0000;
	position:relative;
}
#container #header {
	padding: 25px;
	height: 50px;
	width: 775px;
	border: thin dashed #999999;
}
#container #content {
	padding: 10px;
	width: 400px;
	margin-left: 200px;
	border: thin solid #0066CC;
}
#container #footer {
	height: 100px;
	border: thin solid #663300;
}
#container #left-sidebar,
#container #right-sidebar {
	border: thin solid #FF9900;
	position: absolute;
	width: 200px;
	top: 105px;
}
#container #left-sidebar {
	left: 0px;
}
#container #right-sidebar {
	right:0;
}

The sidebars are absolutely positioned- a technique I use because (a) I hate sidebars that stretch further than the content column and (b) I like to be able to push content further up in the source order so as to feed that stuff to search engines first. If it was an issue and one or both of the sidebars needed to drive the height and source order didn't matter I could tweak it to satisfy those requirements. That said, this is my party so I'm going with the absolutely positioned sidebars Other than that, it should be pretty self-explanatory to anyone familiar with modern layout techniques. UL id="container" takes the place of the traditional "wrapper" type DIV, the LIs take the place of the other section DIVs one might expect to find in any site that uses modern techniques and none of the actual CSS is all that different than what one might expect with a regular DIV based layout.

I know what you're thinking- why is this even useful? To be honest, probably not. DIV's are fine for this job. Separating sections of a site are what they're designed for, so there's no shame in using them for this purpose.

[devil's advocate]
There might be less "extraneous" markup with this technique since the UL is necessary as part of the list structure and the traditional div id="container" or "wrapper" is only there for the purposes of layout. Also, the connection between the sibling LIs might be stronger semantically than the connection between the adjacent DIVs which don't have any unifying structure. Other than those incredibly geeky points I'm not convinced there's much to this beyond the thought experiment value of it all. Which is valuable. I'm just not sure I'm going to actually build any sites with this technique any time soon.

Or maybe I will.
[/devil's advocate]

Shout in the comments if I stopped making sense at any point in this post. I started yawning about thirty minutes ago so I can't be sure of anything I've written in that time

*which isn't to say I'm not down with DIV's. I'm on the DIV train, I just know from painful experience that valid, table-less code with millions of nested DIVs can be just as miserable as any old school, nested table beast.
**which translates to the company's desire since I'm driving the "how" of our front end practice

Hallelujah. Bravo Microsoft! I really don't like using JS to embed Flash into a page, so this is good news for me. No more SWFObject for me

Don't get me wrong, SWFObject is a great piece of code. I just hate having to think about Flash at all. Unless there's actual communication between the SWF and the page, I just want to dump it into the doc like any other element and be done with it. I can't tell you how many problems I've had over the past year with Flash and JS embed techniques and bizarre bugs… Pain. Great pain.

IE Automatic Component Activation (Changes to IE ActiveX Update)

Back in April 2006, we made a change to how Internet Explorer handled embedded controls used on some webpages. Some sites required users to “click to activate” before they could interact with the control. Microsoft has now licensed the technologies from Eolas, removing the “click to activate” requirement in Internet Explorer. Because of this, we're removing the “click to activate” behavior from Internet Explorer!

It’s important (and cool) to note that this change will require no modifications to existing webpages, and no new actions for developers creating new pages. We are simply reverting to the old behavior. Once Internet Explorer is updated, all pages that currently require “click to activate” will no longer require the control to be activated. They’ll just work.

IEBlog : IE Automatic Component Activation (Changes to IE ActiveX Update)

Yahoo! is training front end developers to fill their staffing needs…

The Harvard Of JavaScript Training (Yahoo! Developer Network blog)

When you think of prestigious law schools, it's Harvard. Computer Science? Maybe MIT or Carnegie Mellon. When it comes to front end engineering though, Yahoo! Juku may be the best bet. Taught largely by our in-house front end pros, including YUI developers Nate Koechley, Yahoo! Juku Nicholas Zakas, and Thomas Sha, and JSON inventor Doug Crockford, Yahoo! Juku is a comprehensive, 3-6 month program to train professional front end developers. The curriculum includes advanced topics in JavaScript, DOM, HTML, CSS, YUI, performance, and accessibility.

Why train raw recruits to this degree? Well, in the San Francisco Bay Area, including the Silicon Valley, it's hard-as-heck to find good front end programmers and web designers. Things aren't as crazy as in 1999, when many companies seemed to grab random people off the street to do front end development, but top talent is still scarce. The first class of 13 Juku graduates will toss their hats into the air on December 14th!

Dear Yahoo! You don't need to go to all that trouble… just open a Boston office or let me telecommute and I'm all yours! I'll even give up "Plain Old JavaScript" and hitch my wagon to YUI full time! That's dedication.

I like the sound of the Email Standards Project

The Email Standards Project works with email client developers and the design community to improve web standards support and accessibility in email.

Our goal is to help designers understand why web standards are so important for email, while working with email client developers to ensure that emails render consistently. This is a community effort to improve the email experience for both designers and readers alike.

I don't do HTML emails very often any more (although they still sneak through,) but we still do a ton of them at Cramer so just for my co-workers' sake I'd love to see email clients come together the same way browser vendors have (finally) come together in order to allow us to code clean, light, standards compliant HTML emails. If I never had to rely again on the dirty tricks we use to get HTML emails to render I would be a happy man. It would also save clients money since the unwieldy beasts we send out are a lot more difficult to maintain and edit than something with nice structure would be.

I'm crazy late on this, but William Gibson posted it just today, so I can't feel too bad about posting it here. If it's good enough for him, it's good enough for me

Anyway, here's an insanely good Latvian Le Parkour video

Paris, Je T'Aime While almost all of the entries were interesting and the film overall was a joy, I did have some favorites:

• Montmartre written and directed by Bruno Podalydès, this was a cute tale of loneliness vanquished by an abrupt courtship. A simple, sweet story.
• Quais de Seine written by Paul Mayeda Berges and Gurinder Chadha, directed by Gurinder Chadha. Remarkable balance between a thought-provoking examination of the "head scarf" controversy in France and a sweet picture of young longing…
• Loin du 16e written and directed by Walter Salles and Daniela Thomas. Simple in concept, but well executed. The bookended lullabies and the long, painful commute that connects them makes for a rich snapshot.
• Bastille written and directed by Isabel Coixet. A beautiful but painful love story executed in five amazing minutes.
• Parc Monceau written and directed by Alfonso Cuarón. Cuarón is ridiculously good. Here he takes a really simple setup and plays with our assumptions in one long take.
• Place des Fetes written and directed by Oliver Schmitz. A stunning achievement for a five minute short. Creatively structured and emotionally engaging, this was easily my favorite of the segments in this film. A truly perfect bit of cinema.
• Pere Lachaise written and directed by Wes Craven. A great little story. A hallucination of Oscar Wilde is in it. What more do you need?
• 14e Arrondissement written and directed by Alexander Payne. I love this segment. I wasn't really sure where it was going, but when it gets there it's just brilliant stuff.