Disco Shiny » Ramblings

Body Classes Can Be A Smart Choice

Kurt — Sat, 23 May 2009 17:28:53 +0000

At my place of work, one of my projects is to develop our department website. Because this is a major website at the university, it has to follow all the rules. These include accessibility, cross-browser support, and conservative design sensibilities. But being a non-technical corporate environment, they want to have their cake and eat it too, so I have to reconcile the JavaScript carousel and scrolling news widgets they wanted with the accessibility concerns for people with text readers or what have you.

I was poking around the internet and found the solution on another page at our university. I believe it was created by our competition, Creative Services, who we’re pretty sure take templates and butcher them to be Mason-branded. The implementation on that page was the answer no matter how much I loathe their cookie-cutter techniques. The answer is classes.

In the past I had dismissed body classes as being a poor design strategy for a site. This was because I’d only ever seen poor implementations of them, parroted by Lynda.com. You should not use classes automatically on every site you design. This encourages inconsistency in design between pages. It also bloats your CSS because if you’re using a class, you’re using a lot of descending selectors and creating styles like .bodyclass #sidebar ul li.

But there are circumstances in which body classes can be used correctly and one of these circumstances is my problem. The idea is to first create your page without any JavaScript functionality at all, but with JavaScript functionality in mind. That carousel of images, for example, becomes a grid of images. The scrolling news shows only the top three items. The animation is not present. Then in your $(document).ready() block before anything else, you do this:

$('body').addClass('js_ready');

You’ve just added a class to your body tag with JavaScript. If the user does not have JavaScript enabled, this will not trigger. So now you can put all your JavaScript styles under the .js_ready selector. Because of the specificity of CSS, adding more information to an element selector will override any other reference to that selector. So if you have #carousel ul li and .js_ready #carousel ul li, any styling in the latter block will override the former, making your page style differently in the presence of JavaScript. This may necessitate updating the prepackaged CSS that came with your widget to include the body selector.

Well that’s a pretty cool thing, and while I was realizing how it worked I thought of another possibility. Admittedly it’s not going to be widely used, but I guess it could make a good tech demo. What if you want to have different themes for your page? Each theme is under a different body class and could be changed via JavaScript. I imagine this would be most handy if you’re pitching to a client and you’ve created a couple different designs and you wish to cycle quickly through them for comparison. The theme change would not be persistent across pages without some extra work, and who wants to create more than one completely realized style per site anyway? But it was a neat idea I had. Maybe I will implement it here on Disco Shiny…

Blinded By JavaScript

Kurt — Tue, 12 May 2009 06:30:09 +0000

Before about a month ago I had never touched JavaScript, I thought it unnecessary. I had been able to do everything I ever wanted in CSS, and if some task could only be done in JavaScript, then it was not a task worth persuing. Well as of a month or so ago, I began a project at work to create an invoicing system. I’ll get into the specifics of the project in some other post, but a large part of it was using jQuery to create a true dynamic web application. Picking up jQuery does not strictly imply that you pick up JavaScript, but they are rather close enough that you begin to see the majesty and wonder of being able to manipulate the DOM so freely.

This is a trap. I fell for the trap.

A large part of the web designer’s job is to translate a mockup of a design from Photoshop or something into HTML/CSS. This means looking for logical divisions of content and thinking about how the box model can help you achieve this layout. When I created the current design, I saw two columns separated by the fake 3D effect and said “Ah! I will have two columns! One of them will have the repeating background trick and an image each at the top and bottom!” Easy to think, impossible to implement. First off, the sidebar needs to scale with the content, or the 3D illusion is broken. And thus begins my descent (the highest form of patriotic) into the trap. I turned to JavaScript.

All I need to do is grab the heights of the sidebar and content, find which is bigger, and resize the other! Oh, but I need to take into account the offset. Oh but I need to move that bottom image as well. And after not too long, I’ve created something that functions. Hooray. Unfortunately, this is a problem for a number of reasons,

It is highly inelegant. It’s overly complicated and the browser should be doing it for me.
The syntax highlighting code breaks it because it takes longer to execute
It can be easily solved in CSS with a little more creativity

Look, all that needs to happen is have the content div be the combined width of the current content and sidebar divs, images at the top and bottom (use an inner footer div that clears both and has an image background), and then have the two columns with no image backgrounds just take up however much height they need and let the browser sort it all out. That’s what browsers do best.

I got caught up in the shine. I saw what JavaScript could do and was tempted to make bad layout choices by the fact that JavaScript can be used to crutch almost any situation. Learn from this. Think long and hard about each thing you want JavaScript to do. Can it be done no other way? Could you handle it in either the PHP/ASP/Perl/Python or the CSS? Because you should. Here are some things which you can and sometimes should use JavaScript for:

Animation. This is a whole can of worms, another post maybe.
AJAX and all that cool web 2.0 stuff
Form validation. Can be used with number 2

If it’s not one of those things, think again.

This post brought to you once again by the

tag.

Thoughts on Cross-Browser Coding

Kurt — Fri, 08 May 2009 16:37:30 +0000

I’ve met some people who hold low opinions of IE. Scratch that, I’ve met a whole lot of people for whom IE doesn’t butter their bread. I’m one of these people. These people tend to be web developers, because IE did a number of unfortunate things for people looking to create websites beyond the very baseline. There exist a number of “danger zones,”

Transparent PNG support
z-order
Rounded corners
Floats and margins
Expanding boxes

Okay that’s all I can think of off the top of my head. The point is though, that none of these things are strictly necessary for a website. It’s easy enough to create a site that looks pretty much the same in IE5.5+ and the Firefox/Safari/Opera crowd, but if people choose to use a more modern browser, including newer versions of IE, the site will only get shinier.

Point of all this is, the people who don’t like IE and actively leave out fixes for it are not really professional level yet. Professional level developers neutrally regard or hate every browser equally. Firefox 2 has some weird layout issues, for instance, on sites that look fine in every other browser! CSS 3 support is still handled differently by everyone, each browser supporting a subset. The list continues.