Web Design Articles

Illustrating the Potential Power of Design

By Louis Lazaris / August 18, 2010 / 5 Comments

In our industry, those who are well-trained in the principles and strategy of design (no, I don’t think I fall under that category) put much emphasis on the potentially powerful effect that a good design can have.

Design that is arbitrary and unplanned might succeed simply because of its ease of use, or its familiarity. But design that is well thought out and planned with specific goals in mind has the potential to cause users or customers to make decisions that they might not normally make.

Yes, I suppose this is a form of manipulation and some people might not agree with it. But I think as long as you stay within certain boundaries, manipulation through design doesn’t cross any lines, and it’s really just a tool at the disposal of the website/owner/designer.

Don’t Use PHP for Browser Detection (for CSS)

By Louis Lazaris / August 16, 2010 / 54 Comments

In the comments of a recent article discussing conditional comments someone mentioned that they prefer to use PHP to detect which browser (user agent) and/or operating system is in use, then they display a custom class for the <body> tag and target the browser accordingly in their CSS.

I’ve known for some time now that this is wrong. I was told that a user agent can be faked, so the people I’ve worked with discouraged this method, and I’ve never used it.

In no way am I an expert in this particular area, so I’m not claiming here to be able to fully explain exactly why we shouldn’t do this, but a little bit of quick research on this topic shows that server-side browser detection is not a good idea.

I’m not going to drag each of these points on (mostly because I don’t have the technical expertise in this area), but instead I’m just going to provide brief quotes and links that discourage the use of this method and provide further insight into the matter.

Stop Perpetuating the Myth — People Do Read Online

By Louis Lazaris / August 10, 2010 / 36 Comments

This post might sound like an opinionated rant, so I apologize up front for that. But sometimes I write stuff because I get annoyed at how quick people are to jump on bandwagons and follow trends, and it often comes out sounding a little harsh. Even I’ve been guilty of following trends at times, as I’m sure we all have. But sometimes we have to be a little more honest about the realities of our industry.

This myth about the lack of reading online has, from what I can tell, spread to virtually all corners of the internet market, and I think it has gone too far.

First let’s clear up a few things: I’m not denying the research that has been done in this area, and I’m not saying that we should ignore those findings. Instead we should recognize the importance of gaining loyalty in readership, and work towards creating content that users will look forward to reading. Let me explain what I mean.

Things You Might Not Know About Conditional Comments

By Louis Lazaris / August 3, 2010 / 43 Comments

Use of conditional comments to target certain versions of Internet Explorer is pretty commonplace nowadays, and is generally seen as the best-practice method for including separate styles for IE.

Of course, I’ve argued in a previous article that if your IE-only styles are minimal, then you should just include them in your main stylesheet, a notion that others have echoed.

But conditional comments have some unique possibilities and quirks that maybe you haven’t considered before, or have simply forgotten. Here is an overview of some things you may not know about conditional comments.

Making Unobtrusive JavaScript Practical Again

By Louis Lazaris / July 28, 2010 / 20 Comments

Maybe it’s just me. Maybe I’m a JavaScript debugging n00b, or maybe it’s my limited knowledge of Firebug.

While I fully support the use of unobtrusive JavaScript in all projects, I do find it has one weakness: Connecting the HTML element with the code that acts upon it.

If you’ve been coding JavaScript since the dark ages of the web, you’ll know that JavaScript used to be commonly implemented in an obtrusive fashion that mixed markup with behaviour, which made your code messy, and added extra code to every individual page rather than putting it in an external reusable file.

Here is a simple example:

Nothing to See Here — Just a Redesign

By Louis Lazaris / July 13, 2010 / 16 Comments

Over the past week, I’ve redesigned Impressive Webs, and today it’s launched. The last design got old quick, and I felt it wasn’t as good as it should have been.

This design didn’t take me too long, since the basic structure and layout of the site is still somewhat the same. I think it’s a little cleaner and more professional looking, and it was certainly influenced by some of the great designers I’ve observed over the past year or more while blogging regularly.

I’m hoping that certain features of the design will allow for creativity within individual posts at any time in the future, should I decide to venture into that area of design blogging.

IE-only Styles: Where Should They Be Placed?

By Louis Lazaris / July 6, 2010 / 26 Comments

Dealing with Internet Explorer is a fact of web design, and it isn’t going to go away anytime soon.

If not for some of the differences in the way IE6 and IE7 handle certain areas of CSS (whether it be margins bugs, float bugs, or other problems), CSS development would be so much easier.

Of course, as I’ve said in past articles on this website and others, I believe IE-only styles can be kept to a bare minimum, and in some cases you may not need any, but it’s unlikely that developers will end up so fortunate. So how do you divide your IE-only CSS styles? The options we have are as follows:

The Complete Guide to Commenting on Web Design Blogs

By Louis Lazaris / June 29, 2010 / 58 Comments

I think it’s safe to say that the voice of the audience in the web design blogging community has had a tremendous effect on the quality and honesty of web design-related articles.

Since opinions stated in blog comments often have the potential to misrepresent what the author has said, I thought I would put together an exhaustive reference of tips and recommendations that will help all of us become better at commenting on the different web design blogs that we visit each week.

So please consider applying the advice in this article in order to improve the communication level on web design blogs, and to help all of us move forward in a positive direction as we try to become more skilled at coding, designing, developing, and maintaining websites.

Coding for IE6 = Progressive Enhancement

By Louis Lazaris / June 22, 2010 / 22 Comments

It was disappointing to see the unwarranted uproar that occurred in the comments of my article on Smashing Magazine on cross-browser CSS. But in retrospect, it was probably a good thing, because a more important (but related) issue was brought to light in the discussion.

At this stage in modern web design, all front-end coders should at least be familiar with (if not very capable of implementing into their projects) the concept of progressive enhancement. In most cases, we tend to associate progressive enhancement with JavaScript and CSS, and rightfully so, because those technologies help us layer our functionality in a way that makes a website accessible to as many people as possible.

But progressive enhancement isn’t just limited to what we accomplish with fancy Ajax, jQuery, and CSS3 — that’s just part of it (albeit a very significant part). I would like to take the Wikipedia definition of progressive enhancement just a little bit further. Here is the definition:

Should You Ever Use Longhand for Padding and Margins in CSS?

By Louis Lazaris / June 21, 2010 / 13 Comments

Most CSS developers eventually come to learn that, because of code savings, using shorthand notation is usually best. For this reason, I strongly recommend using shorthand notation for almost all CSS values, including padding and margins.

While I encourage developers to use shorthand for padding and margins, I would also like to point out that there will be times when using longhand notation may be the better choice. Of course, in a case like this, it’s usually up to personal preference. But I have found certain instances where longhand notation made more logical sense from a performance perspective, as well as from a future-maintenance perspective.