Tips for Reviewers & Requesters
When reviewing a Web site, do so in a more detailed manner. Often I see replies such as, "Lose the tables for layout, use CSS and semantic, meaningful markup." In fact, I see such replies too often. It casts a careless atomosphere about, and causes a very negative attitude. A better approach would be to explain how and more importantly why. If you're in a hurry or sidetracked, perhaps you should avoid replying until you can dive deeper into the site you are reviewing. Often times, if you are replying hastily, you either miss important things or appear careless. This is frustrating. Parents, though not particularly interested in "childish games," participate to show their love. In the same way, we should review Web sites with care, even if we are not interested in the actual purpose of the site. Don't try to review every site, unless you feel lead; you are not obliged to respond to any one of them. I say this because, again, a careless, quick response often turns out negative. The purpose of this forum is more to help web developers see their errors and possibly learn new design skills, ideas, and useful practices. I believe if we are more specific and careful, our posts will be much more positive, convincing and helpful.
I am going to explain a few things which are relevant to any design you make. Most of these statements are technical.
- Validate your HTML. In every web site you ask to be reviewed, someone is going to check the validity of your HTML code. You can use the W3C HTML validator to beat them to the punch, however. What is valid HTML? Allow me to explain further. Each document requires a document type declaration (DTD). You have to define, in the first line of your HTML code, just what is allowed. If you don't, browsers revert to a default one (usually, though not always, HTML 4.01 Transitional). A DTD specifies all allowed HTML elements. If you use an HTML element that is not in the DTD specification - whether or not it "works" in the browser - it is invalid. More information can be found at <http://www.w3.org/TR/html4/struct/global.html>.
- Do not use tables. The purpose of tables is for tabular data - what you see in Excel spreadsheets. Columns and rows. Using tables for layout makes absolutely no sense. For you it may be different, but chances are if you want to design with tables, you don't suffer from any form of disability. There are many blind, dyslexic, and other handicapped users who browse the Internet. And, though you may not realize it, these sites can become very confusing. What's more, the W3C has a specification regarding accessibility. You should always respect and obey the rules set by the W3C; doing otherwise is promoting bad practices and discouraging the proper use of recommended technologies. The Web Content Accessibility Guidelines specify all the rules that you should take into consideration when designing a site. It is generally a good idea to avoid breaking any of them, but you should always strive for priority 2 accessibility (known as "AA"). You may notice, in the WCAG (Web Content Accessibility Guidelines mentioned above), that it says you can use tables for layout if they linearize. This is absolutely not recommended, as it breaks priority 1. It means, basically, if you can see the table-based layout well enough in a text-only browser, then your layout is bearable. However, it is breaking priority one and therefore is a very bad practice. Instead of using tables for your layout, use Cascading Stylesheets. Their purpose is for Web site design. Their use also saves you file space and bandwidth (because of cache). You can include a single file on each page and use minimal markup (excluding actual text content) to turn 8KB files into 4KB ones. Need more reasons or a longer, more in-depth explanation?
- For users with CSS: use valid CSS. Colored scrollbars, proprietary "filters," and the like are not recommended W3C technologies and are not specified in the CSS2 specification. Hence, they are invalid CSS and should not be used.
- High-contrast hurts, but helps; high-contrast helps, but hurts. "It's a cool site! It has a black background, red text, and an awesome fiery header image!" So it's valid HTML, CSS, and uses semantic markup. That's great, but how's it on the eyes? Black backgrounds tend to be strenuous. These high-contrast sites can be difficult to view for a lot of users. However, don't turn around and use a white background with light-blue text that is not readable. Make sure your colors contrast enough, but not too much. Often a white background with medium-colored text or a medium-colored background with light text is the best choice (though light text on a light background may work well sometimes). You want your text readable and not strenuous, but you don't want the site to look ugly as a result. This is a key point for those of you who are on free web hosts (see below); when first starting out, you may like the black background and red text, however it is tough on the eyes and 99.9% of the time is the worst choice you can make. Updated: 10/16/04.
- Test your site in multiple browsers. Do you browse happy in a browser, or do you muck around the Web in a proprietary markup translator? Hopefully the first. There are alternatives for your default browser. Check your site in other browsers to ensure that it functions properly. If it doesn't, you're probably breaking priority 2 somewhere along the line.
- Avoid free web hosts that give advertisements. It's acceptable to use if you're just beginning, and need somewhere to place your work for others to view, but do not try to make a free host your perminent residence. Advertisements - popups, banners, especially - are very annoying and will cause your site to look much different (worse) than it would in the first place. Added on 10/16/04.
That's it, I hope this post helps those reviewing sites and requesting their site to be reviewed!
Last edited by Jona; 01-30-2005 at 03:21 PM.
i agree. I'm one of the people that always say to use css. i would explain it but so many people use tables and to explain it everytime would be heck. As I can see you have made a nice little page of this stuff, and i think you should sticky this page...nice
Thanks, Boooze. It seemed necessary that there be some basic information pre-written for everyone, rather than us repeating the same thing all the time. Also, thanks to Pete for making this sticky.
Hey you put in the time to write this the least I can do is make it a sticky!
I decided to make it a sticky way before I got though reading it.
Very well done Jona, gj
And I was wondering if reviewers could at least take the time to find SOMETHING about a site that they like. Even if it's the fact that it works.
It gets discouraging, to get a few dozen reviews that state what's wrong with your site, and nary a peep about what's right.
Mr. Initial Man, reviews often focus on the negative side of things. This is not uncommon. Until your site looks good to a person, he most likely will not say, "it looks great"; instead he will focus on what he does not like, and once it is changed/resolved, he will agree that it looks nice. Unless he dislikes the entire design, which may be the case sometimes; but most often any design can look nice once reviewed and modified accordingly. It does get very discouraging, and possibly frustrating, but again a review is not asking everyone to put butter on your muffins for you, it's asking them to tell you how your muffins taste to them individually. Hope this helps.
Acually, I do something similar, them link to something either I have wrote erlier on my blog, or something like this, Jona. Well done. Hope some admin is not going to murder me know that I have confessed(sortof?)
"Lose the tables for layout, use CSS and semantic, meaningful markup."
I have two problems with that article. 1) Just because it is difficult or impossible to achieve something when going about it the right way does not mean we should go about it the wrong way. 2) What’s this about a Bush flip-flop?!
I don’t like Meyer anymore…
From Zeldman blog entry linked above
and the CSS haters start to crow that Iíve done a Bush-style flip-flop
No matter how you slice it, using tables for layout is wrong.
Edited for major booboo
Last edited by Paul Jr; 11-14-2004 at 10:20 PM.
Originally posted by Paul Jr
I don’t like Zeldman anymore…
Meyer != Zeldman
But yeah, I agree. I don't think it is correct to use tables for layout under any circumstances.
Every fight is a food fight when youíre a cannibal.
I dunno, boys.
Like, sure it feels nice to disable the stylesheet and see your markup degrade into a beautiful semantic linear document... but do real world developers care about that? You can still 'display:none' on a table cell for print or pocket stylesheets.
If this is the vehement fanatical attitude that established developers face when they visit a this like this, it's no wonder they're antsy about switching.
Wired.com has taken a huge step -- but what if they'd given up because someone moaned that they used bald divs instead of uls? Or that the navigation wasn't horizontally styled lists, as is the fashion these days?
Until there's better options presented in CSS3, I'm content to do pure CSS for 2-column, a table for 3-column. You can call table layouts a hack, but it's as bad to have four or five nested containers and wrappers on stuff. I'm with Eric.
Yup It sure does...
Originally posted by mikepurvis
Like, sure it feels nice to disable the stylesheet and see your markup degrade into a beautiful semantic linear document...
I don't know about real world developers but us imaginary ones sure do.
Originally posted by mikepurvis but do real world developers care about that?
I disagree. Since the DIV element has no semantic value, nesting them several levels deep has no other negative affect than increasing the size of your markup (depending on how much you nest, that's only a little, and still less than nested tables). It's perfectly acceptable to nest DIVs; they're generic style containers, they're pretty much meant for that kind of thing.
Originally posted by mikepurvis
You can call table layouts a hack, but it's as bad to have four or five nested containers and wrappers on stuff. I'm with Eric.
Using tables for layout, however, is always bad. The TABLE element is not intended to do that, doing it can severly bloat your markup, and make your site difficult to use for people with disabilities.
Dude. By real-world, I mean like the guys that actually work for real companies maintaining corporate websites, not the fringe community of design-bloggers who engage in occasional contract work or 'consulting'.
Originally posted by the tree
I don't know about real world developers but us imaginary ones sure do.
Yes, Zeldman did a great job with Amnesty. But is it a 3-column layout? No. Is it a liquid layout? No.
I will probably never use tables for layout again, but I don't think it's a helpful critique to tell someone to 'start over' because they've taken an approach that may exclude the 0.000001% of surfers who require a dramatically altered stylesheet.
Just to put a little perspective on this, I surfed to my recipe site on a pocket PC, and it loaded the Screen stylesheet, for some reason. When I did the same on a Blackberry, it showed unstyled content, but then also collapsed tables cels-- obviously a strategy employed by the browser to linearize content.
In neither case did it display the way I intended. Granted, I didn't provide a pocket stylesheet, but it was discouraging, considering that a large part of the standards movement is an attempt to increase the accessibility of the web.
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)