Posts Tagged ‘browser’

It’s Our Fault IE6 Still Lingers

Thursday, February 12th, 2009

Roger Johanssen’s post “No more pixel perfectionism in IE 6” is a clarion call for web developers the world over. We need to stop bending over backwards for IE6. The argument that “we can’t stop developing for IE6 because of the number of people still using it” is a fallacy. I’m convinced that the very reason why IE6 is still hanging around is because we keep going out of our way to make sites work in it. The moment that IE6 users see that most of the web is broken in their browser, they’ll switch.

A colleague of mine told me this morning that the reason why a lot of people still use IE6 is because they don’t have a legitimate version of Windows, so they’ve turned off Windows Update. That’s fine, they don’t need to upgrade to IE7, they can use Firefox, Opera, Chrome, or Safari!

So in the tradition of the last such clarion call, I say to hell with IE6!

Update: Der Caspers makes a good point about IT folks being the ones not wanting to upgrade. In fact I just had a conversation about this with someone yesterday. I can only think of one reason for why IT people won’t upgrade, cost. Unless it’s laziness, otherwise, it’s cost. Security isn’t the reason, IE6 has 22 out of 135 vulnerabilities that remain unpatched. To say nothing of the fact that “To help customers become more secure and up-to-date, Microsoft [began] distributing Internet Explorer 7 as a high-priority update via Automatic Updates and the Windows Update and Microsoft Update sites” in 2006! So my recommendation to these IT folks is to get themselves into the modern era and ditch that anachronism that is IE6. Before somebody gets hurt.

Be Lazy, Let the Browser Do the Work for You

Friday, April 11th, 2008

Imagine you work for a company that has an online product catalog and that your job is to maintain the product images. Now imagine your boss comes to you and says, “here’s a list of a thousand products that need to have ’40% off’ put on them, and we need it for tomorrow, noon.” So you work all night only to have him come to you in the morning and say, “did I say forty? I meant fifty.” Now you’ve got till noon to update a thousand images, go! The more efficient way to handle that situation would be to have a macro, or a template, or some other automated way to either update those images or just superimpose the discount on each of those images.

The moral of the story is, work smarter not harder. When a computer can do the work for you, let it. There’s no glory in doing it yourself. This same moral can be transposed to front-end web development.

There is this thing called “flow” in the browser environment. Think of it as a really crude physics engine. All of the elements rendered in a page are initially a part of the document’s flow. When an image within the flow is enlarged, the text adjacent to it gets shoved over. When it’s reduced, the text is drawn closer. This is good because you don’t need to worry about positioning the text when playing with the size of an image. It’s handled automatically by the browser.

Now imagine if you were to break the flow and opt to position everything yourself. Maintenance would become a nightmare. Sadly this often happens when people get their hands on CSS and don’t know how to properly leverage it. Instead of letting the browser handle the positioning of the elements and just nudging them in place with a few strategically placed rules, they opt to brute force everything into position. Of course, what happens when an image size changes? or a bit of text goes longer than anticipated? Everything breaks. Then they’re up all night fixing a ton of style sheets.

The thing to remember with CSS is: less is more. Really, the cascade works best in conjunction with document flow. Restraining either too much defeats the purpose and leads inevitably to unnecessary headaches.