Tag Archives: web design


I have been reading a lot about microformats recently to try and get a better understanding of them, their benefits and how they affect web standards. I’ve talked a little about them in the past but I wanted to delve more into detail.

The basic idea of microformats is to design a standard XHTML template for common items – for example a hcalendar for events. That template is then the standard for all items of that type. Since all of those items share common elements – in the hcalendar example a h3 with class = summary would be the event description – they are easily able to be encoded into XML and can be aggregated. So sites or programs could aggregate sites using microformats and parse them into easily understandable and standard (hence web standards) displays.

It opens the doors to easily sharing contact information, events, resumes and people relationships with friends, family or even across the web. There are even, already, some microformat plugins for WordPress and noted blogger and CSS expert Eric Meyer uses them for both his tags and his blog watch. I definitely need to track down a rel-tag plug-in to start getting indexed in Technorati – any suggestions?

I realized I’ve only scratched the surface here. With that in mind I’m going to forgo my usual random tidbit and list some links to sites I found filled with microformats information. Before I do, note that already there have been concerns about identity theft with things like hCards and hResumes so there are many bugs to yet be worked out. It’s a powerful tool though with lots of possibility.

For more microformats information check out the following or my microformats tag on del.icio.us:

Do people still use tables for layout?

I am surprised by how many sites still use tables for layout. This was a practice adopted during the “browser wars” because of the low acceptance of CSS – for complex designs the only method available was to use tables. This is no longer the case. Now with web standards and CSS sites can be designed as they were intended – using markup for the purposes the creators meant for them: h tags for headers, p tags for paragraphs, div/spans for non-semantic elements and, finally, tables solely for tabular data (think spreadsheets like excel). Then you use the CSS for design and layout of the site.

Getting off my “web standards” soapbox for a moment the main reasons you want to avoid using tables for layout is that they bloat your markup. This makes it difficult to change and update your site and it hurts your ratings in search engines. By using the correct tags you naturally tell search engine spiders what your content is – a keyword rich header, a content rich paragraph or a navigation list. This allows them to better match your site to keyword searches and increase your audience. You also don’t have to change multiple pages of markup when you want to redesign your site – you simply edit your CSS and never touch the markup.

There are some instances where you want to, and should, use a table.  When designing the table you still want to keep standards in mind. In the old days you would use inline tags like “align” or “valign” for td’s and “cellpadding” or “cellspacing” for the table itself. Now all of that can be done through the CSS. Simply place a class on the table – or use the containing element of the table and apply the rules that way.

For example if you have a table inside a div with class “mySite” you could vertically align the td’s simply by using the following rule:

.mySite table td { vertical-align: top }

If you had used valign = “top” on all of those elements and then later on you decided you wanted to change them to centered you would have to go back and either do it by hand or via a find and replace. Using CSS and web standards you could simply change that one rule and affect all of the elements. That is the true power of it.

In conclusion, the most important thing to remember is to only use tables for the purpose they were created for – tabular data. When using them for this also remember to use the least markup possible. No presentational elements should be present – only semantic elements like content and semantic images (one that add value like logos or photos rather than are used for display like rounded corner containers). Also, if you find yourself placing tables within tables reevaluate your markup – you’re probably using this to create layout or presentation and could get away with a single table and CSS to style it.

Random Tidbit: Having trouble selling web standards to your boss?  The Web Standards Project can help.  Plus they have probably the best example of a site using web standards in every facet – which makes sense.

The age old question – fixed vs fluid (vs. elastic)

Fixed vs. flexible design is one of the main arguments of the modern web design era. Much of the argument derives from the fact that IE (Internet Explorer) did not support the min- and max-width properties until version 7. As of this date version 6 and lower are still in such high usage that you cannot count on these properties to work. So the question “fixed vs. flexible” is asked at many a new design meeting.


What is fixed design? Fixed design is essentially defining a width on a page – no matter the size of the browser window. You can find fixed designs at sites like Helium, CNN and Yahoo. A typical fixed layout has containers, text, images and most other elements defined in pixels.

The main benefit to designers in using fixed layouts is that they have total control over the design. Unlike traditional media outlets – like newspapers and magazines – the web can be viewed through a large variety of devices from cell phones to PDAs to computer screens to widescreen HDTVs. With traditional media you always know how your page is going to appear. With the web, the same page viewed on a cellphone and a computer can appear vastly different – or even 2 computers with different screen resolutions. Fixed layouts give a designer more control over how their content is viewed. Finally, because you are defining the layout of the page you have more freedom with background images – if you notice the examples above all but CNN make extensive use of background images for design.

There are 2 main faults of fixed designs. One is that users with large screens and resolutions viewing sites with small widths have lots of wasted space. This is a bad user experience because you are dictating to the user how they should experience your site. The second is that if a user is using a smaller screen or resolution some of your design might flow outside the window – causing the dreaded horizontal scrollbar. This also creates a bad user experience.


What is fluid design? Fluid design essentially allows the user to decide the how the page looks based upon the size of their browser window and display settings – the page “flows” (hence fluid) to fill the entire available space. Fluid designs can be found at sites like Google, Wikipedia and Reddit. A typical fluid layout has containers, text, images and most other elements defined in ems or percentages.

The main benefit to designs using fluid layouts is that they can use all of the space available to them. The philosophy is that you can’t predict the user’s setup so you want to make your design as adaptive as possible in order to increase the user experience. A fluid layout puts the control of the design in the user’s hands.

There are 2 main faults with fluid design. One is that if someone has a very large/small screen or resolution your site can appear “wonky” – extremely long/short lines of text and distorted containers. The second is that fluid design makes it extremely hard to use background images because of container distortion. They require vast amounts of testing in order to function properly – if at all. In the examples above none of the sites use background images extensively – which severely limits your design creativity.


A new design not mentioned in the title goes by several names and is basically a hybrid of the two. It uses min and max width (using javascript for IE6) to try and get the best of both worlds. Basically it defines a range of values in which the design can flow – so that you still have some control over the design (like fixed) but users with larger screens/resolutions can expand the width somewhat. 456 Berea St and Digg use something along these lines.

The main benefit of hybrid/elastic is that it gets some of the benefits of both fixed and fluid – users and designers split control over the design. It’s main fault is that like any hybrid it doesn’t do either of those things as well as the original.

So which is better?

If you haven’t figured it out by now, there is no right or wrong answer. The correct choice depends on the purpose of your site and your design preferences. The sad fact is that any choice you make is going to alienate some user. The old saying is that “You can please some of the people all of the time and all of the people some of the time, but you can’t please all of the people all of the time.”

Typically if you have a site with shorter blocks of text and/or you are more Web 2.0 you lean towards a fluid design – utilizing large font sizes to lower the impact of some of it’s faults. If you have a site with long blocks of text – like a news or article/blog based site – then you lean towards a fixed width design.

Random Tidbit: Speaking of design what about Time.com’s 50 coolest websites?

Designing for cross browser compatibility

One of the best and worst things about the web is the fact that when it comes to your choice of web browser the program you use to access and view the internet – you have multiple options. From the standard Internet Explorer (PC) or Safari (Mac) to open source projects like Firefox to outsiders like Camino and Opera.

The problem is that all of the browsers interpret (X)HTML – the code websites are written from – very differently and all of them have their own internal style sheets and form controls. What this basically means is that a site designed in one browser can look vastly different in others especially older or non-standards compliant ones like IE6.

There are 3 main ways to deal with browser compatibility issues – having the right tools, designing with web standards, and utilizing filters or conditional statements to feed alternative styles to less compliant browsers.


The first step to dealing with cross browser issues is to design in a compliant browser. In most cases, the best one to start with is Firefox. The simple reason for this is the vast tools it gives a web designer to pinpoint problems and quickly debug code. Two of the best are the Web Developer’s Toolbar and Firebug.

The Web Developer’s Toolbar gives you the ability to edit CSS on page to test fixes quickly, to outline specific elements, disable cache easily to enable testing (since CSS is cached naturally) and many other useful features outside the scope of this article. Firebug is one of the best design tools available allowing you to inspect elements on the page, see the cascade of styles applied to that element to narrow down bugs or rendering issues, and even allows you to edit the (X)HTML on page so that you can quickly test for different scenarios. Both of these will save you a great amount of time while you are designing your site.

Web Standards

Web standards is the practice of writing (X)HTML using standards compliant code – basically utilizing correct tags for elements, using CSS for presentation, markup for content, and limiting the amount of markup to the least amount necessary to complete the task and provide enough “hooks” for your CSS. Some of the benefits include improved Search Engine Optimization and the ability to re-design your site later on simply by editing the style sheets. The other benefit is the fact that you use CSS for presentation – allowing you to deal with presentational issues relating to browsers easily.

After getting your markup done it’s time to style your site. The easiest way to avoid compatibility issues later is to reset the styles on all elements. This is done because different browsers use different styles for elements. One might naturally put 10px of padding on a p tag and another might put 10px of margin. This is the root cause for many rendering issues found later. A good reset style sheet was posted recently on Eric Meyer’s site.

If you’ve done both of the above then you are now setting yourself up to have the least amount of issues possible. Depending on the complexity of your site it might look exactly the same in most of the browsers – Firefox, Safari, IE7 and (hopefully) IE6. If not, the next step is to utilize filters and conditional statements.

Filters and conditional statements

Filters should only be used when nothing else can. If you have designed in Firefox then at this point you should have no issues in that browser. Internet Explorer will be covered in the next paragraph. Opera has no way to filter CSS to it. It typically has few rendering issues that do not pop up in Firefox though and any that do typically you must live with. The only browser not mentioned is Safari which does have a large user base. In your main style sheet you can define styles to target only Safari by using the following rule:

:: root (parameters) { styles }

So now you’ve covered the most compliant browsers: Firefox, Safari and Opera. The only one left is IE. IE has it’s own set of filters but utilizing them is not advised because they get messy as you have to override main styles for IE6 then in many cases re-override those for IE7. The best practice is to use conditional statements. You simply define additional style sheets – for example looking at the source of this site you’ll see a sheet called mainIE6.css – and put the rules for those browsers in them. Microsoft has defined conditional statements that can then feed those styles to whatever IE version you define and only IE. The standard way to do this follows:

<!–[if IE 6] (style sheet link) <![endif]–>

Other operators beside if include lt (less than), gt (greater then), lte (less than or equal) and gte (greater than or equal). So lte IE6 would target IE6 and below. The operator gte IE7 would target IE7 and above – and so on.

Now you have the tools to correct any rendering issues that might pop up.

In conclusion, the best way to deal with cross browser compatibility issues is to limit the chance for them to appear by using the right tools, standards compliant markup and CSS. Some issues will always appear and the few that do can then be handled by using either filters or conditional statements. Remember always to test in multiple browsers to find the issues. At a minimum your suite should include IE6, IE7 and Firefox. If you have access to a Mac then Safari should be included as well.

Random Tidbit: I really like SEOmoz. I like their article on getting traffic from Digg comments even better – though I’m a bigger fan of Reddit personally.

Modular Web Design

So I’ve been reading a lot about modular web design. Basically what it stands for is creating a web site – essentially a template – in such a standards compliant and well thought out manner that redesigning the site later on requires you to only modify the CSS file. It’s not a new concept – it’s something that was introduced when CSS was created and made famous by the CSS Zen Garden. Recently sites have been recreating their own personal zen gardens allowing for quicker redesign turnaround.

It’s a process I’ve used since I read up on the Zen Garden. The last 3 sites I’ve done – including my own – were done off a basic template. In essence it was a wire-frame design. And now, if I wanted to update any of them – and I’ve done small ones from time to time – I have enough hooks typically to just add or modify CSS rules. Though this doesn’t work if you go from a simple design, like my site, to a more complex design – with things like rounded corners especially. In those cases you will have to modify the XHTML.

Though it’s simple it’s not a process all beginners can copy though. And it’s an excellent learning tool. So later this week I hope to upload 2 templates – one being the wire-frame and one a more meatier zen garden-esque template. Stay tuned.

Random Tidbit: Along with Web 2.0 has come a new workplace. An article I saw on A List Apart talked about the “Long Hallway” – basically it talks about how in the new workplace designers/developers can collaborate from home offices around the world, building a team with no set office.  It’s something I’ve been thinking about for awhile and very interesting.