Thinking inside the box

— Topic: css

I know, you're thinking - "Who does this guy think he is, he's in 9rules for two days and he's already dispensing tips?" Well, yeah, but not because I consider myself an expert. Rather, it's because I'm so average that I have such a keen insight to the mind of the normal human being.

Comments Popup

That being said, there are a few things that have been on my mind lately, the first of which is the way commenting systems work on blogs. Some have great ones, such as the style pioneered over at Snook.ca and some have typical ones, such as the comment form on my own site. Now, this is not going to be an article on how everyone should use fixed CSS positioning for their comment form. No, it's far more simple than that.

At my school Asbury Seminary, there are quite a few students who blog using Blogger, LiveJournal, Xanga, etc. I have noticed that on many of their blogs, when you try to leave a comment, a JavaScript window opens. This seems like no big deal at first, but half the fun of reading comments is clicking on the person's name to view their website.

When you do this, if comments are in a popup window, it launches yet another window with <target="blank">. There is a reason this was deprecated in XHTML 1.0 Strict. In my opinion, launching other windows via this method is an insult to the intelligence of the user. Most people know enough to open the link in a new window if they want to, and the more tech-savvy will just open it in a new tab in Safari/Firefox.

So, while a little JavaScript popup might be merited in some cases, such as for contextual help, having popups that spawn more popups is going a bit too far, in my opinion. So, if you're a blogger and are given the option, please choose a comment form within the normal browser window from now on.

Box-Model Hack Work-around

This next tip is not so much a usability tip as one to help designers. I have read a lot of the big-name designer's sites in efforts to improve my own skills. I have also struggled to get certain things working correctly in cross-browser situations. Awhile back, an article entitled Exceptionally Negative got me thinking about the box-model hack.

The point of this article at SimpleBits was to lessen the "indentation" of certain elements within the flow of a document, so that they have more emphasis. The principle in effect is not that different than what I had already done on this site, except that rather than give things a negative margin, I have simply given other elements more positive margin.

This brings me back to my point about the box-model hack. Recently there have been articles circulating as to why CSS hacks are ugly, and how to use work-arounds to provide alternative solutions. Consider this one of those solutions. Rather than fuss with CSS hacks to make adjustments to the padding of a <div> I have simply not given any padding to any of them on this entire site.

So now you may be wondering how to go about having the correct spacing in your content. Well, the method is the inverse of that described in the Exceptionally Negative article. Rather than pulling elements to the left, we are pushing them to the right. For instance, here is a simplified example of the CSS for SonSpring…

#content h2 {
	margin: 0 15px 10px;
}

#content h3 {
	margin: 0 20px 10px;
}

#content p {
	margin: 0 25px 10px;
}

In case you're not familiar with CSS short-hand, the time and space-saving technique that is all the rage these days, the above <h2> code means…

margin-top: 0px;
margin-right: 15px;
margin-bottom: 10px;

So wait, now you might be wondering, "what happened to the margin-left?" Well, in CSS short-hand, the order for margins is defined as Top, Right, Bottom, Left, or TRBL (Trouble) for short. Since there is no margin-left defined, it simply inherits the value from that given for margin-right, which is what we want, so that we have equal margins on each side of the content, much like a printed page.

So, there you have it, a simple bit (pun intended) of code. The more important the element, such as <h2> titles, the less side margin they have, adding increments of 5px with each "indentation." There is no need to worry about Internet Explorer rendering the margin or padding incorrectly, because you have not set a defined a set pixel width. It simply assumes that the inline elements will have a 100% width, and adds the buffer as needed.

Now, you could argue that this not the way it should be done, because these block elements aren't meant for positioning. Yet, on the same token, where does it say in the WC3 recommendation that we should use @import to hide all our ugly hacks from the validator? It's a trade-off either way, but I leave that up to you as the designer to decide.

I just find it much more easy to maintain one CSS file without hacks, rather than try to remember what browser responds to what hack, or try to maintain multiple versions to @import. That has allowed me to use only two CSS files for this site, one for screen and another for print. I have also started alphabetizing my CSS to make it easier to find things, but that is entirely a personal preference.

I just thought I would share the way that I do my CSS coding, in hopes that it might benefit others out there who are frustrated with Internet Explorer. In my opinion, it is a far more simple solution than CSS hacks, which I will leave to people much smarter than myself.

Me, elsewhere