The W3C has worked hard to remove presentational elements from HTML. Unfortunately, old habits don’t die easily. This has resulted in some standard generic CSS classes that are contradictory to the intention of HTML and CSS. If you are using classes like .left, .right, and .clear you are guilty as charged.
Outsourcing IE6 bug fixes: good or bad idea?
I found a very interesting idea by Tim Van Damme, which examines the possibility of a service that fixes nothing but Internet Explorer 6 bugs, much like the slicing/PSD-to-HTML niche that’s grown in popularity over the past years.
I guess that’s how troubling IE6 has been to us. Who here hasn’t delayed fixing up websites to make them work properly in IE6 until the very last minute? Who here hasn’t cursed IE6 and Microsoft (and even Bill Gates) a million times? Who here can’t relate to the (humorous) pie chart below?
Clearly there are problems with such a service, like how it’s too specific and biased against a single browser version—surely there are other browser bugs a web developer must pay attention to. And how letting others do the bug-fixing for you might bring about even more complications and wasted time anyway.
Never mind how long this business will actually last. It still begs the question of how to deal with cross-browser compatibility the right way. And the answer is, it really depends from site to site, company to company, audience to audience. Some things to consider:
- Have you tried avoiding styles that are trickier to fix for IE6?
- Can’t you leave those rounded corners just square ones in IE6? Or make those translucent effects opaque?
- Would you consider doing taking more stringent action by dropping support for IE6?
I think Kai said it best, it’s “a business idea that shouldn’t have to be one!” But it still makes for an interesting discussion. When you’re faced with stumbling blocks while developing for IE6, what would you rather do, roll up your sleeves and do the dirty work yourself, or ship it off elsewhere?
The Fun Is Over: Remove Those Falling Snowflakes Now
We have all seen it, those falling snowflakes. They are everywhere this time of year. In principle, I like the idea of decorating your site or blog for the holidays, it’s nice. However, some things should just not be done.
Like falling snowflakes, all over the page.
But the problem is, everyone has seen it already, and it was annoying the first time around.
Yes, I know, it is easy to add one of those scripts to your site, and at first glance it looks nice. But the problem is, everyone has seen it already, and it was annoying the first time around. The thousand time, it makes me close the tab and go someplace else.
Another thing that I loathe with decorated websites is the addition of sound. This is luckily not as common anymore, which goes for websites overall, but for some reason the madness spreads in December. Please don’t ever make your website play music per default! Sure, add a play button if you think your readers will want to hear a midi file playing Jingle Bells or whatever (my guess is “no”), but don’t autostart it please.
Also, don’t force an animated Christmas card on me, just because I have the nerve to visit your site. I don’t want to see that when typing the URL, I want the actual site. Not a crappy Flash animation, the site. Link it from there instead, if you want to wish your visitors Happy Holidays, and then the ones in the holiday spirit can watch it and go awww, while the rest of us can use your site as intended.
Snow on your logo. Been done, but OK. Same goes for a festive background image, added details to the corners of your existing site, things like that. That’s OK, it can even be a bit nice, although I get tired of seeing the same green clipart over and over again.
The key to decorating your online presence is to not hamper the actual site!
Keep that in mind until next year. Now please remove those falling snowflakes.
Now, that being said, have a Merry Christmas and a Happy New Year!
Web 2.0, Future Creep, and the Irony of Frameworks
I was recently accused of over-implementing my projects at work. How audacious! How un-Web 2.0! How true. The fact is, over-implementation is one of the big downsides to Web 2.0. We have more frameworks than ever, for example:
- CSS: YAML, BlueprintCSS, and YUI
- Javascript: jQuery, Prototype, MooTools
- PHP: CakePHP, Zend, PHPDevShell
There is a ton of functionality packed into each of these frameworks—most of which are geared toward speeding up development. However, with all this added functionality has come the tendency to overbuild everything.
Gone are the days of single-function onClick validation scripts. Now you must load an entire library, call anonymous functions, focus on reusablity. Before you know it, what could have been handled in 3 lines is now p,a,c,k,e,d into a 30kb JavaScript file that includes plus an extra CSS file as a dependency and 275kb of PNGs.
I find it ironic.
Web 2.0 was founded on simple, elegant design and code. It was feature shy. I bought into it wholesale and went along for the ride and now I am using it to over-implement my projects.
The solution comes (unsurprisingly) from 37Signals who have managed to stay the course all these years. They are still preaching the same message they have been preaching since day one: Less is more.
- Never implement more than you need to
- Never plan further than you can see
- Don’t be afraid of imaginary work
Don’t get me wrong—I think frameworks are extremely useful. However, next time I sit down to write some sweet app I will be thinking a little harder about whether I can get by without one.
Bloatware: How to Avoid Bloating Your Application
I read an interesting reflection by Jeff Chandler over at Performancing. Jeff asks if all software is destined to become bloatware, and then applies it to blogging platform WordPress. While I don’t agree with the Google Chrome – Mozilla Firefox comparison, basically talking about how much faster and sleeker Chrome is, it is an interesting question.
So far, it looks like WordPress 2.7 will contain a number of integrated plugins into the core leaving some to believe that WordPress is becoming bloated. Although I am not a software developer, this had me thinking on whether or not all software is doomed to become bloatware.
Yes and no, is my answer. Most software becomes bloatware because it isn’t rewritten enough. Think about it, if you build upon a core that is dated and bulky it will affect everything you put on it. However, if you revisit your old code every now and then, keep it up to date, and rewrite portions (or all) of it, there is really no reason why your application should become bloated.
Think about it, if you build upon a core that is dated and bulky it will affect everything you put on it.
If we look at web applications in particular, we’ve got to take scripting and databases into account. PHP gets updated, and suddenly your old code written for an early PHP 4 version should be swapped for PHP 5 code instead. New database queries can be used to speed up your web application, and so on. In fact, because of this, I think revisiting and rewriting the core of a web application is way more important, than traditional software.
WordPress in particular could probably use a rewrite here and there, at least that’s what people are telling me, I wouldn’t know myself. This is probably something that goes for a lot of open source projects. With the November release of WordPress 2.7, we’ll get a bunch of features that previously was handled by plugins. That means that the core is growing, and one should be wary of that. However, this isn’t necessarily an issue, because online you just load what you want to load, and if the WordPress core is organized in a decent manner, that means that the extra stuff won’t be called for unless needed. I’m not really worried about that.
I am, however, a bit more concerned about walking in old tracks, which is another kind of bloating I guess. If you’ve got a great idea in 1.0, you build upon it, and then you build upon it, and build some more. And you know what, then you’re stuck in it! It would be awfully hard for WordPress to lay off the categories, for instance, and every larger revamp they do to the admin interface will turn a lot of people off.
That’s why we get new projects, like Habari.
Any piece of software, online of off, can be bloated. That doesn’t mean that it has to.
What do you think? Share your thoughts in the comments.
