I’ve found that the best way to keep on top of the available tools for web development is simply to maintain communication with other developers, finding out which products they like, which products they don’t like, and why they choose one option over another. So – what’s in your toolbox? Post some comments & let us know. Below is a list of a few of the tools we use over at Context to make our lives easier and make our clients happier:

Drupal (Content Management)

There are several content management systems we’ve worked with and have had good experiences with, but as we move forward, Drupal seems to be the winner in terms of features, scalability, and support. I suspect we’ll be using Drupal as the CMS for all projects in the foreseeable future, and I strongly recommend looking into it if you haven’t already. One thing I will say about Drupal is that its power isn’t at all apparent from the default install, so make sure you browse the documentation a bit in order to gain an understanding of just how much Drupal can do.

Magento (E-Commerce)

When it comes to E-Commerce, Magento takes the cake in terms of architecture, scalability, and customizability. Its architecture might be a little bit intimidating to some developers (it’s built on MVC and EAV), but its potential is just limitless. Most of the complaints I’ve heard about Magento seem to stem from a lack of understanding of MVC development, or a poor configuration of mySQL that leads to performance problems. Magento does still need some performance enhancements, but those enhancements are being addressed in an upcoming release slated for this month, and even now the speed is quite acceptable if you have mySQL tuned properly. I’m very interested in hearing alternatives to Magento, because I haven’t come across anything yet that, in my mind, is a legitimate competitor.

Fuse (PHP Development Framework)

Our own homegrown MVC framework, Fuse is definitely our weapon of choice for any custom PHP development. We’ve even successfully integrated it with Magento and Wordpress (e.g. the blog you are reading right now). Built to give us the flexibility of Rails but the freedom of using PHP, Fuse has grown into a very powerful competitor in the PHP/MVC world.

jQuery (Javascript framework)

If you’re not using a javascript framework, please start today. Even if you go with Prototype over jQuery, you’re doing yourself a disservice by not leveraging one of these phenomenal tools. It’s almost hard to quantify how much hassle we *don’t* have to go through to add historically tedious functionality like drag & drop, ajax forms, and dhtml popups. jQuery can turn an hour or more of tedious coding into a 30 second task – maybe a minute and a half if you first need to Google for the function name & available options.

I think we’re all patiently waiting for a standard way to embed any font into a web page via CSS, but adoption of the CSS3 standard for embedding fonts has not only seen slow progress, it has been met with opposition due to potential copyright issues. You can read more about the woes of standard cross-browser font embedding here.

However, you won’t have to wait until the CSS3 issues are worked out to be able to embed clean, anti-aliased, non-web fonts in your page without resorting to embedding text in images. The answer is here, and it’s called sIFR, the scalable Inman Flash Replacement.

Some people have called sIFR a hack, I just call it clever. And it’s no secret on the web – it’s been around in some form for quite a while now – but it seems that a lot of people I meet in the web design or website development business either haven’t heard of it or haven’t actually tried it.

sIFR works through a mix of CSS, javascript, and Flash. It performs surgical replacement of page text with dynamically generated flash movies, and those movies contain the replaced page text in the correct, non-standard font. Now, that may sound a bit overly complex and kludgey, but sIFR is packaged in a clean, easy, robust manner that works across browsers and allows a very fine level of control over the text replacements.

Let’s take a look at an example:

THIS IS MYRIAD PRO (which is not a standard web font)

The heading above uses a standard <h2> tag that is transparently replaced by sIFR with the flash movie containing the Myriad Pro font. One of the best things about sIFR is that if the user agent doesn’t support flash, it degrades gracefully into the default font for an h2 tag, so the user still sees the text. You may also noticed that you can highlight and copy the text as if it were a normal <h2> tag.

There is a lot of documentation on sIFR at the sIFR site (make sure to use sIFR3 for the best results), which should allow you to get things up and running quickly.

sIFR opens up a new world of web design freedom when it comes to choosing fonts. While I wouldn’t recommend replacing every bit of text on the page using sIFR, it works exceptionally well for headings and subheadings. We implemented sIFR quite a bit on the Native Eyewear website, and were very pleased with the results.

There are alternatives to sIFR such as Typeface.js, but so far sIFR seems to be the most reliable candidate for providing freedom of font choices in your website design. Your designers will be happy knowing that sIFR is in your toolbox, trust me!

Update (again): I had initially uploaded a jQuery based fix to get this selector working in IE6, but Emil Bjorklund pointed out that Dean Edwards’ IE7.js also fixes the issue, so I would recommend using that script to get the selector to work in IE6.

Recently, we’ve been making substantial use of a CSS selector that I stumbled on almost accidentally in the w3c docs: the “~=” selector, which can more compatibly be written simply by separating class names with a dot (and no spaces) . It’s certainly no secret, but I haven’t seen it in use much, and that’s a shame because it lends itself to some really clever and intuitive CSS. Here’s the definition for the selector:

Matches any E element whose “foo” attribute value is a list of space-separated values, one of which is exactly equal to “warning”.

It doesn’t sound too interesting, but what we’ve found is that it lets us use very intuitive, almost straight English syntax for our css classes by daisy chaining class names in a logical order.

Consider the situation where your template has a main content area, sometimes with a sidebar, sometimes without. There are plenty of ways to handle this fairly simple problem in CSS, but I’m finding the most elegant solution to be the following:

.main_column {
    min-height: 300px;
}

div.main_column.with_sidebar {
    float:left;
    width: 690px;

}

Now, when our main column needs a sidebar, we can do:

<div class="main_column with_sidebar">

<!-- Content here will be floated left -->

</div>

Why is this better than just defining “.with_sidebar”? Because it may be the case that two different classes (maybe “main_column” and “page_content”) both support a “with_sidebar” version that applies different width & floats depending on which class it’s being applied to. (“main_column .with_sidebar” won’t work because “with_sidebar” is not a descendant class of main_column.)

Taking it a step further, let’s add a green background:

div.main_column.and_green_background {

background-color: green;

}

now, how about:

<div class="main_column with_sidebar and_green_background">

<!-- Content here will be floated left with a green background -->

</div>

Again, there’s nothing here that can’t be solved in other ways, but I just wanted to introduce other people to this oft overlooked selector which, in my opinion, allows for very clever, elegant CSS.