No Mod Required

Here’s it is.

//height for IE6. Thankfully IE6 messes up height in a useful way
height:350px;
//height for everything else. IE6 looks at this and says “wha?”
height:auto;
//min-height for everything else. IE6 is baffled by this.
min-height:350px;

I can’t tell you how many times I’ve used this exact pattern. It actually works really well, it’s just so wrong it bothers me each and every time I type it into a style sheet.

It works because the first height declaration, in pixels, is rendered by Internet Explorer 6 exactly the way the next two rules are rendered by every other browser. Meaning, it starts at 350px and then expands to fill whatever content it contains. Add to that the fact IE6 is baffled by the next two declarations (not understanding auto as a value for height and not supporting min-height in any way, shape or form) and for IE6 height is all you need.

Thing is, every other browser that matters renders the single height declaration (with overflowing content) like this:

Which is where the height:auto and min-height declarations come into play. Add those in and things start acting as expected with the other browsers- the container starts at 350px and expands to fit the overflowing content.

Since there are no “hacks”, the above sheet will validate, I just hate the pattern of declaring height once and then immediately redeclaring it- especially to support a seven year old browser.

So… IE6? Are you listening? Can you please give up the ghost so I can put this pattern to bed?

Pretty please?

Dave Shea says:

“Did you know that you can nest your divs so deep that Firebug stops working properly? I do now.”

From:

mezzoblue § Design Rants

Personally, I’m surprised because I’ve seen some savagely nested divs produced by systems like Drupal and while it was a singularly awful environment to work in, it didn’t actually cause Firebug to choke. Also, looking through his code, I see nothing that screams to me as being exceptionally deeply nested. I put a comment in. I’ll update with more info…

Remember the “Small Site Enhancement” I introduced last month? For a refresher I linked all of the images in my gallery flow. Instead of simply being static, they now link through to the next image in the gallery flow. I did this hoping to increase the number of page views per user by making it easier for them to click around and do those things that users love to do After nearly a month of the change being in place, I have some preliminary results:

For the period from 2008/05/03 to 2008/06/01 I averaged 4.79 pages per visit

For the period from 2008/04/03 to 2008/05/02 I averaged 4.38 pages per visit

Those numbers represent an increase of 9.37% or .41 pages per visit. I’m not going to make Google tremble, but I’ll take it.

Answer: When it’s a unique identifier.

Check out this class attribute generate by my beloved Wordpress’ upload feature:

class="alignleft size-medium wp-image-4590"

See anything suspicious? I sure do. wp-image-4590 is a unique identifier being passed off as a class. Why? I actually have no clue as I’m not privy to the thought process behind that particular piece of code What I do know is pretty much demands to be an ID. When I teach this stuff to people, I say “If it’s unique, meaning there will ever only be one of them, make it an ID. If there’s more than one or it’s a general descriptor, make it a class.” So I look at that code block every time I upload an image and I frown. Then I blow away the whole class attribute away, since I use none of them.

This is just splitting hairs, I know. Using a class like that is basically harmless. But, truth be told, splitting hairs helps me solidify my ideas about the way these things should work. That, in turn helps me improve the way my crew and I do our thing. So? Hairs I split and everyone is happier.

I’m just doing my small part to make the web a better place one nitpicky, semantic post at a time.

Since I’ve got a few minutes to kill and especially since no one asked, here are my top photos on flickr based on:

Interestingness and Comments

Views

(with 12,585!)

Views (of an actual photo)

(with 927 views)

Favorites

(just 5 :()

and with that I say, “hell yeah.”

Dear Internet, anyone out there have any experience with lightweight web servers that they’d like to share?

We’re (meaning Cramah!) looking to set up an asset server to serve static assets like css, javascript, images, flash (destined for progressive downloads) and mp3s. We want to offload that kind of stuff from app servers as a general architecture approach going forward (my obsession with performance is spreading ) Since it’s (at some level) my baby and is something I’m generally interested in, I’ve taken a little time and starting looking into what the set-up should entail. I’ve done a little bit of research and it looks like the names I already know are the names that people are using:

• lighttpd
• nginx
• LiteSpeed

Based on what I knew when I started, what I’ve read since, and a recommendation from a co-worker, lighttpd seems to be the way to go. Thing is, I don’t want to jump into anything before asking you, the Internet, if there’s anything I should know about it (or the other two) before heading down that path.

So… anyone out there using this stuff and feel like sharing an anecdote or two? Is there some other candidate I’m missing?

All comments are welcome

For real! I ran through all of the primordial webmonkey tutorials* when I was starting out building sites (10-11 years ago now!) and if the newly relaunched site is half as helpful it will be a great boon to the community. Great info and a friendly, funny attitude made it the place for me to learn about the web thing back in the last century. Honestly, I owe a lot to the usefulness of those early tutorials. Looking back on it I realize that Webmonkey, coupled with the community that sprang up around Dreamweaver at the time**, was a great forge upon which to build up my web chops.

We’re Back! Webmonkey Relaunches, Rejoins Wired

The original web developer’s resource has returned. Webmonkey has been completely redesigned, and we’re ready to rock once more. Also, our entire content library is now hosted on a wiki, so every tutorial, reference page and code example is open for editing. Come on in and show us what you’ve got!

Webmonkey: the Web Developers Resource

*Some still exist: like Thau’s JavaScript Tutorial, which is over ten years old now.

**I’ve been a Dreamweaver user since Version 1.2.

Google Doctype, as introduced by Mark Pilgrim:

The open web is the web built on open standards: HTML, JavaScript, CSS, and more. The open web is a beautiful soup of barely compatible clients and servers. It comprises billions of pages, millions of users, and thousands of browser-based applications. You can access the open web with open source and proprietary browsers, on open source and proprietary operating systems, on open source and proprietary hardware.

Google has built its business here, on the open web, and we want to help you build here too. To that end, we are happy to announce the formation of an encyclopedia for web developers, by web developers: Google Doctype.

Google Code Blog: Introducing Google Doctype

Personally, I’m excited by this development (both practically and philosophically) and will likely contribute wherever it makes sense for me to lend a hand. Looking at it quickly some of the HOWTO information is already very useful (the web security information especially) and it will only improve with time as more and more dedicated people get involved with the project.

It was really pretty easy. I submitted it. Lord knows if they’ll accept it, but even if they don’t it won’t stop me from doing another one

Interested in doing one yourself? Google has an excellent developer’s guide.

I made the image in my gallery pages “hot” today. Each gallery image now points to the next image in the gallery flow. It’ll be interesting to see if that increases the average number of page views per user. I’m thinking it will as a lot of people use that technique so I’ll hopefully be leveraging that learned behavior. Logically it just makes sense as those back, home and next buttons are way too small. I’ll report the results in a couple of weeks…

Check it out here.

I’m actually in the process of recoding all the gallery pages (with the exception of the alphabet I posted yesterday, which was built that way from the beginning) to have an actual anchor tag wrapped around the image. For now I’m doing it with a little bit of JavaScript:

var imgs = $("artimg").getElementsByTagName("img");
for (var i=0; i< imgs.length; i++) {
    imgs[0].onclick= function() {
        document.location.href=$("next").href;
    }
}

where “next” is the existing ID applied to the next link in gallery pages. I love being able to use such simple JavaScript to enhance the user experience in such a (potentially) large way.