Web development mistakes

When I visit a website, especially if it’s the site of a competitor or a prospective client, I like viewing source and take a look at what’s under the hood. It’s one of my not-so-secret obsessions. And I am way too often absolutely disgusted by what I see.

The web is overflowing with sites that use horribly invalid, broken, and inaccessible markup. Even sites built by people who have been in the web business for many years, and who really should know better, are full of problems that shouldn’t be there. The reason? Ignorance, laziness, lack of time, bad tools, you name it. Yes, I’ve been guilty of making many mistakes myself through the years. However, I do my best to learn, and avoid making the same mistakes over and over again.

Update: After reviewing the comments made on this post, I have updated the list: Web development mistakes, redux.

Here’s a list, in no particular order, of some of the most common mistakes that even experienced web professionals tend to make:

DOCTYPE confusion
Completely missing, incorrect, or in the wrong place. I have seen HTML 4.0 Transitional used in documents containing XHTML markup as well as in <frameset> documents, DOCTYPE declarations appearing after the opening <html> tag, and incomplete DOCTYPES.
<span> mania
A common way of styling something with CSS is to wrap it in a <span> element with a class attribute and use that to hook up the styling. I’m sure we’ve all seen things like <span class="heading"> and <span class="bodytext">.
(too much) Visual thinking
Treating the web as WYSIWYG – starting off by focusing on how things look instead of thinking about structure first, and presentation later.
Lack of semantics
Non-semantic markup. Basing the choice of which HTML element to use on the way most graphical browsers render it by default, instead of on which meaning the element has.
Character encoding mismatches
Specifying one character encoding in the HTTP header sent by the server, and using another in the document. This may confuse browsers and make them display the document improperly.
Bad alt-attributes
Missing or useless. <img> elements with missing alt attributes can be found in billions on the web. Not quite as common are useless attribute values like “spacer GIF used to make the layout look good”, “big blue bullet with dropshadow”, and “JPEG image, 123 KB”. Remember, the alt attribute is required for <img> and <area> elements.
Invalid id and class attributes

Multiple uses of the same value for the id attribute. Invalid characters used in id and class attributes and CSS selectors.

For CSS:

In CSS 2.1, identifiers (including element names, classes, and IDs in selectors) can contain only the characters [A-Za-z0-9] and ISO 10646 characters U+00A1 and higher, plus the hyphen (-) and the underscore (_); they cannot start with a digit.


ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens (“-“), underscores (“_”), colons (“:”), and periods (“.”).

Browser sniffing
Using scripts, server or client side, in an attempt to detect the visitor’s browser, and send or execute browser-specific code. Very commonly fails for reasons like new browsers, updated browsers, and user agent spoofing (Opera does this by default).
Missing units in CSS
Length values (horizontal or vertical measurements) require units in CSS, except when the value is zero. It’s not like in HTML, where you can type width="10". In CSS, it has to be width:10px; (or whatever unit you’re using).
Browser-specific CSS.
Scrollbar styling, expressions, filters etc. Proprietary CSS that only works in Internet Explorer. Invalid, too.
JavaScript dependency
Making a site depend on JavaScript. More people than you’d like are either using a browser with no JavaScript support, or have disabled JavaScript in their browser. Current stats indicate that this is 8-10 percent of web users. Search engine robots currently don’t interpret JavaScript very well either, so if your site requires JavaScript to navigate, say goodbye to good search engine rankings.
Flash dependency
Assuming everybody has Flash installed. Not everybody has. And most search engine robots do not (Google has reportedly started experimenting with indexing of Flash files, but they still recommend that you make sure all your text content and navigation is available in HTML files), so if your whole site depends on Flash being available, you’re not going to score high with search engines.
Text as image
Making images of text, and not providing a more accessible alternative. Not only does it take longer for visitors to download images instead of text, you also make it impossible for most visitors to enlarge the text.
Bad forms
Inaccessible, hard-to-use forms. Learn to use the <label>, <fieldset>, and <legend> elements, and do not use a “Reset” button.
Old skool HTML
Multiple nested tables, spacer GIFs, <font> elements, presentational markup. So common I don’t really have to mention it here.
Being IE-centric
Coding for IE/Win first, then adjusting for others, if there is time.
Invalid HTML attributes
Using deprecated or browser specific attributes like marginwidth, leftmargin, language, height for <table> elements, and border for <img> elements (in strict DOCTYPEs) just to name a few.
Unencoded ampersands
Many URIs contain long query strings with unencoded ampersands (&). This is invalid, and may cause problems. Ampersands must be written as &amp;.

Did I miss your favourite mistake? Add it to the list.

Update: Note that there is an updated version of this list at Web development mistakes, redux. Please check it before leaving any comments here.

Posted on August 24, 2004 in (X)HTML, Web Standards


  1. So true. Other common mistakes are “divitis” and “classitis”, i.e. overuse of <div> elements and class attributes.

    Using a <div> instead of a semantically better element is bad for accessibility.

    Using classes on almost every element shows a lack of understanding of CSS selectors.

  2. Interesting article, Agreed there isn’t too many excuses for recently created work, but I think you should also add lack of budget to your list of excuses. I shudder when looking at my web sites from 3-4 years ago, but how to get clients to pay for patching up my accessiblity mistakes made years ago?

    And my stupid question of the day is… Why is the Reset button such a bad thing??

  3. August 24, 2004 by Roger (Author comment)

    Jakob Nielsen explains the problems with Reset buttons pretty well: Reset and Cancel Buttons.

  4. ah! Thanks Roger.

  5. “Being IE-centric: Coding for IE/Win first, then adjusting for others, if there is time.”

    You may have this wrong here. If you read it like the following you may realize that this is not a mistake but economic reality for some:

    “Coding for IE/Win first, then adjusting for others, if there is money”

    Looking in from the outside it can be easy to judge. I could send you many links to sites whose navigation breaks in Opera, for example, but Opera may not have been in the project requirements. These aren’t mistakes.

  6. August 24, 2004 by Roger (Author comment)

    Mike P: What I mean is that if you follow standards and make your stuff work in standards compliant browsers first, and then make whatever changes are needed for IE to be reasonably happy, you’ll save time (money) and frustration compared to doing it the other way around. I guess I’m mainly thinking of CSS here. But yeah, I get your point about project requirements.

  7. I hear you too, Roger. To go a bit further, I can see people designing for Firefox first, for example, and then hacking things into shape for IE-Win.

    After that perhaps you then try and deal with IE-mac, Opera and other less popular browsers.

  8. August 24, 2004 by Roger (Author comment)

    On HTML and being IE-centric: IE/Win is notorious for accepting sloppy, invalid HTML, which breaks in many other browsers. IE also accepts well-formed, valid HTML, which works in all browsers. So by using valid HTML from the start, everybody is happy, and it doesn’t take more time or cost more.

  9. Hi Roger — nice overview. I know you’ve sort of covered this in your “Lack of Semantics” section, but I want to single this one out: Lack of headings.

    Too often I see headings either marked up as:

    <p class=”heading”>…</p>

    or even:

    <p><b>Some heading like text</b><br>Lorem ipsum, long paragraph text etc…

    Ooh, it just gets to me. Headings are so simple, yet are so underused

  10. Roger [8], I was single-mindedly thinking CSS, totally ‘forgot’ about HTML, valid HTML etc.

  11. August 24, 2004 by Roger (Author comment)

    Derek: yeah, headings are very popular to mark up in the ways you describe. >-( Obviously, turning off HTML in comments isn’t working too well here. Grr. Gotta do some work on that I suppose.

  12. I’d agree they cover most of the common mistakes found in most websites such as using presentational element types where structural markup should be applied and CSS used instead, and vice-versa.

  13. August 24, 2004 by RichardPW

    One of the first things I do is run a page through a validator - it is the most basic sign of “cluefullness” out there. However, I’m perhaps a bit less strict than you about certain markup. I’m less critical of table-based markup, especially on site which have been around a while and needed Netscape 4 support.

    I’m currently building a site for a small non-profit whose computer infrastructure consists of a collection of elderly Macs. The most modern machine had Netscape 4 as its browser, and so the site I’m building must support it fully (including the backend CMS). So, guess what, I’m building a site in 2004 with nested tables and deprecated elements. However, it validates HTML 4.01 Transitional, there is not a font tag to be seen, and it uses h1, h2, and the rest of it.

    Finally, colored scrollbars are evil, but when the client really, really wants it, I let it through. A bit of pragmatism is never a bad thing.

    (OT: beautiful site you’ve got here!)

  14. “Too often I see headings either marked up as:

    <p class=”heading”>…</p>

    or even:

    <p><b>Some heading like text</b><br>Lorem ipsum, long paragraph text etc…”

    Hi. I have set my sights on being CSS friendly and this comment intrigues me…. tbh I thought the first method was the way you were supposed to do CSS. The second I can see is plain “old skool” and frowned upon. I believed that adding a class to a paragraph tag was good form? Without provoking too much could someone give me a concise explanation as to why is considered bad form? Many Thanks in Advance

  15. It is interesting to hear people talking about designing for one browser or another. I’m sure designing with Firefox and then adapting for others is better than doing it for IE, but I try to do it for neither.

    I now try to build my pages without using a browser until it becomes absolutely necessary. I write down all the structural elements on a piece of paper, and then simply create them in XHTML/PHP. I like to have the entire document complete before opening Firefox.

    From that point on, I try to only work with the CSS. I’ll only touch the markup as a last resort. I have found this approach to be really helpful when trying to deal with older browsers and mobile devices.

    Perhaps it is because I am not a visual designer. I like to think of the visual design as a “skin” that is applied after the fact. Others set out to build a site around a design, but I prefer to build a design around a site. This is a philosophy that really came out of discussions I had with Russ of Max Design, who talked about marrying a fully-working “white site” with a visual design.

  16. August 24, 2004 by tallywacker

    You talk about “whole site in flash”.. just the navigation (menu) in flash is awful too.

    In fact, I hate it so much. The designers here always cook up their designs here with alot of flash in it, and it makes everything hard to update, bad for search engines and so on.

  17. @KeithT [14]:

    The first “fake” heading I described was: <p class=”heading”>

    While this is a step in the right direction, it would be much better to use an appropriate heading tag. For example:

    <h2>Heading Text</h2>

    Then you can create a style rule in your CSS to be applied to the h2. Headings have more meaning and semantic value than does a paragraph with an arbitrary class added to it.

    Hope this helps…

  18. @ Derek F… A subtle but important decision there I see. Redefine currently defined tags rather than go around creating brand new ones with better sounding names. Thanks for the direction…

  19. Something I’d add to your list is designing a site with a fixed width larger than 800px. 800x600 is still a popular resolution and layouts should accommodate it. Too often I’m finding sites that don’t downsize to this resolution without an unnecessary and misleading horizontal scrollbar. Unless you know your target audience well enough to conclude that they’re all using 21” monitors with 1024x768 screen resolutions, of course.

  20. I know this is not a very popular point of view among web designers, but I think it’s rather rude to use a fixed width even if it is 800px or less.

    This would hardly be an issue if it weren’t for IE (although Safari is a bit annoying with its lack of support for min-width). With a good browser, it’s easy to set up a fluid layout without having the lines of text becoming too long (the usual hobby-horse of fixed width advocates).

    Good browsers even allow for dynamic image scaling, which removes the last argument for fixed width. :)

  21. I see far too many examples of poorly named classes (often in conjunction with classitis), named for how they look rather than what they do: .largeblue, .graybox, etc. When the site is redesigned and those gray boxes are now pink with purple borders, the old classnames just become irrelevant and confusing.

    I also sometimes see totally vague classnames that don’t describe anything at all: .color13, .size3, etc. It makes it impossible for another developer to build pages without a crib sheet.

    Classes and ids should be named for their function. Anyone can figure out that “.errormsg” is the class to use for error messages, but “.boldred” isn’t especially helpful, especially when it’s normal weight blue.

  22. Roger, I think what you are refering to is actually called “Inclusive Web Design” …something Steven Champeon and I talked about a few years back at SXSW. See the presentation here:

    Inclusive Web Design For the Future

  23. I don’t see why you call these “mistakes”, a site either works for its purpose or not. The last time I read the W3C Web Standards were not mandatory.

    These are certainly practices that you don’t approve, but calling them “mistakes” seems like an obvious mistake to me.

    My fav web development mistake: Blinded by W3C standards rather than real world IE standards there exists, losing money, by wasting too much time on a site (that won’t have any value in 6 months) to make it W3C compliant.

    (I believe forgiving/accepting IE standards are better than W3C standards -needs to be documented though-, and W3C failed to define such a standard, pity).

    Best regards, Burak &

  24. If I had to pick a single web design mistake, it would in an instant be when designers fail to declare a background colour since their browser’s default background colour is the same as the intended background colour.


    Oh, and FTR Burak, IE can render much of the CSS specs (the fundamental ones, if you will such as the box model, fonts, etc), so I am apt to disagree there is a set of standards for a single browser like IE and a set of standards for every other browser. More like a set of standards implemented by many browsing manufactures, and a bunch of lazy practises implemented by people who are too ignorant to realise that developing for W3 standards reduces development time and increases bottom line profit by saving money.

  25. August 24, 2004 by benny

    perhaps the biggest mistake is all of the techo-fascism that dictates that we all have to conform to “standards”. Personally, why should I care if the 3% of the visitors use a text-based browser, or if 5% cannot use my site? What do I care what the W3C thinks of my sites? If over 90% of people have flash installed, why should I care about the 9% who do not? Shouldn’t I care more about what the client wants to use as a base for their designs, as opposed to what an arbitrary party (as the useless W3C) thinks?

    As far as semantics—who cares if the markup isnt semantic? As long as the vistor sees the same thing in all browsers (which is still done in a most fool-proof manner with nested html tables, etc), why should the visitor care about the “correctness” of the underlying structure? Lets face it, there are limitations to sites built exclusively structured by CSS. Most of the sites I see by CSS aficionados look very simplistic—just a bunch of square boxes—and when there are images used as mastheads, they are often one big image (such as ALA). Does it matter to the mainstream user if the site they are looking at include spacer gifs? No. Of missing alt tags? No.

    This whole evangelical “standards” movement over the past few years reminds me a lot of the politics of the left—driven by ideological conformity. Just as the left use “political correctness” to enforce ideological conformity, the CSS evangelists use a sort of artistic/semantic correctness to enforce their ideological conformist notions. And in both cases, when there are dissenting voices to their agenda, then the ad hominem starts to fly—the professional merits of designers start to come into question, etc.

    A lot of what makes this world a good place is that we use different languages to express ourselves. Colloquialism for example, (in language) may not be grammatically correct, or even semantically grounded, but it comunicates the message efficiently; same with slang. Why limit ourselves to rigid, arbitrary controls (of wankers like Jakob Nielsen, et al), as opposed to functional pragmatism in a continually evolving irrational binary universe?

  26. I’ll just attach this airplane wing with bubble gum and duct tape, 90% of the passengers won’t even notice…

  27. Well… About those IE standarts vs. W3C standarts. The problem is, that IE renders HTML/CSS more like it would seem to be correct way if you read that code as plain english. Sorry, but Firefox often are just pain in the ass to make some elements to shrink/grow according to their containers. Also there is that fact, that W3C states, that height is between the inner margins. WTF?? If I say the <div> should be 20px height, then it should be. Because all other neighbouring elements do not care about it’s inner height, but the whole - thus I have to do math… It’s not hard, OK, but why? Also this new XHTML/CSS rullez, tables su… It’s not possible to build highly dynamic page using only CSS. It’s just not possible to position them correctly (although, if you would spend 90% your time positioning them, maybe you would succeed), also, the big issue what happens, when the window is resized smaller than usual. Again bad things happen. CSS only is good only for blogs like these, for corporate projects with realy lot of different info it’s just pain… What Microsoft does, it tries to make developers life easier, but it seems that W3C has gone on to a crusade for “no more peace for developers out there, you have more standarts to conform”. All these talks about correct style in web pages are just made for nothing. When creating projects, the main issue is time. And these W3C standarts take awfully lot of time. btw. it’s lot easier to adapt IE specific page to Firefox than the other way. It’s a fact, proven itself a lot of times.

  28. “it’s lot easier to adapt IE specific page to Firefox than the other way.”

    It’s a lot easier to design for no browsers than ti is to design for one and then adapt for others. That is what standards based design is all about.

  29. August 25, 2004 by Tim Hill

    re: Benny (if that is your real name =) ) “why should the visitor care about the ‘correctness’ of the underlying structure”

    They shouldn’t most of the time. Your client will though, because of the cost benefits of using a standards based design. Less table in a table in a table design and less code. You are looking a lighter site with the same design.

    Don’t think you can build the same design? Check out http://www.csszengarden.com / or check out how Douglas Bowman just did the microsoft site with standards. Throwing Tables Out the Window.

    It seems to me that you are on the wrong side of the boat, get aboard before you drown. better coding practices are here to stay.

  30. You forgot, using non well formed XHTML. This is the most irritating mistake on the Web. I mean, why use XHTML instead of HTML if it’s not well-formed?

  31. August 25, 2004 by Vilx

    One thing I cannot understand - why not use tables within tables? The only real argument that I found in the article above, was that the final HTML takes up less size. Except I did not understand - what takes up less size - only the HTML file, or the total file size needed to browse the page (HTML + CSS file + all else).

    Tables within tables are easier to code & understand semantically. Especally with PHP - index.php serves as a framework, which does SID and other vaidation; then include(“other frames”) in the right places of the big main table as necessary. Also, sometimes there are layouts, which are very difficult to reproduce (and maintain) with using just one table.

    The only other way I know of reproducing this would be using frames or iframes, but that is an even worse style (think of all the text-only browsers!)

    Also, making no-table layout, as I understand, involves CSS Level 3 or something. Well, anyhow, Levels 1&2 have no such possibilities, and we do want to make our pages compatible, no (hell, this is what this article is about, no?)

  32. Vilx, you’re incorrect about being unable to create table-less layouts without resorting to CSS3. If you look at http://www.csszengarden.com/, as mentioned before, you’ll see for yourself. If you would like to know why this is ‘better’, try out some of the links in the ‘places to go’-section on this site, or read Designing with Web Standards.

  33. “It’s not possible to build highly dynamic page using only CSS” — knagis

    My PHP script site

    Both of those are done in full CSS. You CAN make complicated designs using only CSS. It only took me 3 hours to build out that second site with just CSS (normally take me about an hour with tables). Once you understand it, it is so simple. The main reason I would use CSS is to separate content from design. This IS important. After 4-5 nested tables, search engine spiders stop going through your site and just leave.

    I used to build most of my small client sites with table-based design. However, (very) recently I have nailed down this CSS stuff and it doesn’t take much longer to build a site. I can now SELL (make more money) these skills by talking to my clients about SEO and provide a very quality product.

    For larger companies, separating content/design is a HUGE advantage. You often have designers and programmers working together, and this makes life much easier for both.

  34. Good rundown. My personal daily peeve right now is Flash dependancy, the bloody thing is everywhere. Since when was it essential that a website was animated? Blah.

  35. August 25, 2004 by Roger (Author comment)

    Well, judging from some of the comments, there still are people out there who do not want to use web standards or build accessible websites. Some even seem to take pride in creating browser-specific, invalid table tag soup. To each his own, I guess.

    Just remember, that even if you do not see a reason for learning and using web standards, there are good real-world reasons to avoid making several of the mistakes mentioned here.

  36. August 25, 2004 by Lance Hill

    I never noticed how much overuse of Flash there is on the web until I installed the Ad Block extension on Firefox. Now, when I visit a site any Flash element on the page gets an ad block sticker over it. This is great because now I can see all the static images and simple roll-overs that are done in flash. scratches head and wonders

    The last company I worked for did e-learning. Our own site was so badly done I suggested to the boss we should fix it since this is our public face. I even showed her that only the first page was accessible without using Javascript. Then I went on to show her that someone had written some buggy browser-detection code that would not allow anyone to navigate the site if they had any browser other than IE. And don’t even get me started on the tables nested 8-9 deep. After some consideration, she decided it would take too much time to fix, so it was left in that state. Of course, the work we produced for clients was no better.

  37. Tables within tables are easier to code & understand semantically.


    How is this:

    My paragraph.

    more semantic than this:

    <p>My paragraph.</p>

  38. August 26, 2004 by Marcel

    Personally, all I care about is to have a working website. It should work on the most used modern browsers, look good, and be fast. My customer does not give a damn whether or not I used a DIV where it wasn’t absolutely necessary.

    Give me a break. You’re focussing on the wrong things from a having-a-business point of view. In my spare time projects I’d agree, but when I’m working for my boss, all I care about is my deadline and making the site work.

  39. August 26, 2004 by Roger (Author comment)

    Marcel: How can building a better, faster, more accessible site that works for everybody, ranks well in search engines, and takes less time to develop, be focusing on the wrong things?

  40. August 26, 2004 by Ketan Vakil

    Another common one: Bad page title tags = shooting yourself in the foot with search engines.

  41. Facts: (1) W3C standards aim at making the browser writing easy. (Not making web developers job easy). [This is stated on their site] (2) W3C has failed with SVG, Flash is the web animation standard when you consider the meaning of the word ‘standard’.

    So DOCTYPE confusion is a ‘mistake’? How? If it works with the target browsers (and the page is known to be obsolete in 6 months), why should anyone bother to write one? If you spend your time writing the DOCTYPE when it seems completely unnecessary, how is that faster? (Repeat this reasoning with your remaining ‘mistakes’).

    I believe that W3C has failed with their current web standards, because they made it easier for machines, not humans.

    Why should ever a human produce a strict XHTML? Because programs can understand it easily? I think they got it all wrong. In fact, it’s very easy to define strict specs… Why not take the hassle and create accepting specs? I wonder what they do at W3C (probably they party at workshops day and night)…

    Why don’t we use machine code when programming? Why do we use keyboards? Why do we have screens rather than blinking leds? Historically, always machines got closer to humans. But those standards are clearly a step back.

    What I don’t understand is why people are blinded by them? XHTML is worse than HTML 4. (Equivalent XHTML page uses more bandwidth then the HTML page for one).

    If search engines work better with XHTML, it’s because they are primitive and they should be upgraded, as well as any accessibility software which have problems with tables.

    We definitely need standards but better ones, not worse ones than we currently have.

    Best regards, Burak

  42. August 26, 2004 by Vilx

    Reply to comment 37: Of course, You can overcomplicate everything. :) But Your example looks rather synthetic to me. How about show me some real-world example, where it would be better without many tables? (A link, perhaps?) Anyhow, I still think, that, when properly used, nested tables can make things significantly easier.

    OK, one more thing… “Too much visual thinking”. Hmm… isn’t webpages all about how they look? OK, functionality comes first, but the second most important aspect with web-programming is how a webpage looks, no? And all this comparing how it works in different browsers - isn’t that mostly to just synchronize webpage appearances? Because (as far as I know) most Javascripts work the same on all browsers (except maybe some very freaky IE-only stuff you can do without anyway). The same for other things. When I built my webpages, I had no functionality problems on different browsers, only that they each displayed the page differently & it was a nightmare making them all look the same (hey, do all browsers interpret CSS equally?)

    To my mind, visual thinking and WYSIWYG is not only acceptable, it is ABSOLUTELY NECESSARY when building webpages (except for that WYSIWYG editor in IE ;P ).

  43. August 26, 2004 by Roger (Author comment)

    Burak [41]: From About the HTML 4 Specification:

    This document has been written with two types of readers in mind: authors and implementors. We hope the specification will provide authors with the tools they need to write efficient, attractive, and accessible documents, without over-exposing them to HTML’s implementation details. Implementors, however, should find all they need to build conforming user agents.

    Yes, it can be hard to read, but the info is there.

    The DOCTYPE decides which rendering mode browsers use, so it’s hardly useless.

    Vilx [42]: Visual design is important. I have never said anything else. But to some people, the design is all that matters. They don’t care much for functionality or content, as long as it looks good to them. That’s what I mean by “too much visual thinking”. And no, the web is not all about looks. Ask someone using a screen reader. Ask Google. Ask someone using a text-only browser or someone with images off because of a slow connection.

    Some examples of why nested tables should be avoided:

    Nobody is forcing you to use web standards, so if you don’t want to, by all means don’t. Just understand that some of us find that using standards makes our jobs easier.

  44. OK, my last take: If I only care about IE6 and Firefox 0.9 (quirks mode), and without writing any DOCTYPE my pages display OK, and I know that in this age everything ages quickly - the site won’t last more than a year (that is I’m aware that I’m producing something to be consumed for a limited time, as opposed to a piece of art that will stay around for a thousand years), is even knowing about the DOCTYPE necessary? Sure, it does something. But if the defaults work OK, why bother? On the contrary, it takes time and bandwidth. I’d say that, in the above case, including a DOCTYPE is a mistake… Best regards, Burak

  45. August 27, 2004 by Vilx

    Hmm… Still… OK, I have no more complaints, but… 1 question:

    I checked some CSS-only pages (no tables), and they used a LOT of <div>s. They were used in about the same places table tags would normally go. Doesn’t that make the code look as bad as with tables? I mean, it simply looks like we have replaced one tag with another. Styling is possible for both. Perhaps even more for tables than for div’s.

  46. August 27, 2004 by benny

    There is that one very solid point to creating pages, or parts of pages—where it works, with CSS. The reduction of the filesize. The Microsoft makeover, pointed out by #29, is a brilliant example of a saving of thousands in bandwidth over a long period of time. That is a “better argument” for CSS.

    I agree with you in this: in the short-term, it may be quicker (thus cheaper) to code a tabular layout, started in Photoshop, sliced in ImageReady and imported into Dreamweaver. But it would be cheaper in the long-run to build a scalable one in CSS. But the big but to me is: sometimes it is best to use a mix of CSS and tables, which may not be technically correct according to the narrow standards of W3C.

    But what starts to kill me is this part: when everyone starts to say things like “What would happen if someone with a text-only browser couldn’t access that IE-friendly site?” That is like saying maybe we should make the roads and highways more accomodating to someone who might wish to drive a horse and buggy on them (!?) If the are using a text browser, they are still in the early nineties, which in “internet time” would be analgous to someone in the 1920’s driving a horse-drawn coach.

    Why should we always govern ourselves based on what a very small percentile of the population want, and them impose it (usually though some sort of guilt mechanism) on everyone else?

    Burlak’s argument (#44) about the DOCTYPE is a cogent, rational argument as to why it is not really neccessary, and not a mistake to not use it.

  47. August 27, 2004 by Roger (Author comment)

    Vilx [45]: Sure it’s possible to produce crappy code even if you don’t use tables for layout, but most CSS-based pages do tend to have much leaner markup with little or no presentational code in the HTML. That makes the page more flexible and easier to adapt for other media, like mobile devices and printing.

    benny [46]: I see what you mean, and to some extent I agree. However, making sure everybody can access a site’s content does not make it less usable to anyone, so I don’t see a reason not to do it.

    The DOCTYPE argument, well, if you use a table-based layout with lots of presentational markup, see no need for validation, only care about IE6 and Firefox, and the site will be taken offline in six months, sure, go ahead and leave it out. In that context, the DOCTYPE is a very minor problem.

  48. No, it’s not like a horse-and-buggy road, though we do allow Amish folks to drive on the shoulder in the country.

    Instead, it’s more similar to “why should we put a ramp in front of our building. Only 8% of people are handicapped, and we don’t care about them because it is such a small number.”

    A few percent of any audience is significant, and eventually there are going to be legal issues with making places of business online accessible. Part of this accessibility is having the page be understood in browsers that disabled people are using, such as screen readers (which is basically an audio text browser) and other devices.

    Most people who are using “ancient” browsing techniques are doing so because of a disability, and we would do well to accommodate those people just as we do physically in the real world.

  49. August 27, 2004 by caffenero

    Ignorance, and lack of skill. These are the only motivations that can be used against the adoption of standards.

    I’m designing my personal website using ONLY css2 and xhtml, and firefox to preview the results. I use complex css2 and simple, semantic html markup. All the complexity is into the CSS, the page is fool-proof, almost no spans, no IDs etc. Yet the “so-hated” standards let me works in a simple and coherent way… contextual selectors, etc.

    After building for firefox, I decided to see how things looked like in the other browsers, expecting some “need-to-fix-for-(browser name here)” issues… Well, I was AMAZED when both Opera and Konqueror rendered the whole page EXACTLY like they should, as firefox did. NOT a single different pixel, and remember, I used complex CSS2. This is the power of standards… this is no nerdy mumbo-jumbo.

    Oh, I forgot. As always, IE screwed the whole thing up. I fixed the poor dumb browser with the help of Dean Edwards wonderful work (http://dean.edwards.name/IE7/).

    Laziness. :/

  50. “How about show me some real-world example, where it would be better without many tables?”

    Vlix, quite honestly, I cannot think of a single real-world example that would be better with nested tables. In other words, every real-world example I can think of can be done better without nested tables—or even a single table—for layout.

  51. August 27, 2004 by Nexi

    css vs. tables Complete(?) reference guide against standards.

    I wasn’t convinced though.

  52. Empty (or abracadabra) titles

    Constructions like these

    <title></title> <title>some_abracadabra</title>

  53. On the topic of using tables/css: I have not yet seen HTML authoring software that renders tables correctly. I use Visual Studio.NET for creating ASPX pages and every time I’ve managed to fix my table(cells) with the proper width, VS.NET “does” something to mess it up :-). And It’s not just Microsoft! I’ve also seen Dreamweaver messing up my correct HTML. To prevent this from happening I use DIV/CSS.


  54. Is there any documentation to support Derek’s assertion that spiders leave a site with nesting > 4-5 levels deep (comment 33)? I think findability is an incredibaly important aspect of web design which standards based design anwsers, and facts like this help build a compelling case in support of it. Let’s not forget Google is blind.

  55. August 29, 2004 by inkheart

    “Does it matter to the mainstream user if the site they are looking at include spacer gifs? No. Of missing alt tags? No.”

    i guess no “mainstream” people are blind.

    if standards are, as you say, analogous to the politics of the left, then your attitude is comparable to those of the right: do what makes money quickly and please people who remind you of you, since they’re the only ones who matter anyway.

  56. August 31, 2004 by Stan Vassilev

    The comments regarding Flash are all wrong.. first of all that “everyone does not” have flash inside… if 2% is “everyone” then I’m willing to accept this statement. Then that “search engines do not” have Flash installed. Wrong. Yahoo crawls Flash links, Google does, as do many other search engines. Now who’s developing in 1996? Update your information!!

  57. August 31, 2004 by Roger (Author comment)

    Stan: I think you misinterpreted the part about Flash and “everyone”. Let me rephrase it: Not everybody has Flash installed, so requiring Flash is making your content inaccessible.

    As for search engines, yes, there are reports of search engines crawling some Flash files, but Google recommends that you do not yet rely on this feature, and advise you to check your site in a text-only browser like Lynx.

  58. *Multiple nested tables, spacer GIFs, elements, presentational markup. So common I don’t really have to mention it here. *

    Hmm.. I really don’t see the problem. If constructed well it will be displayed 100% accurate in almost every browser. Something that can’t be said to lot’s of CSS / XHTML centric sites.

    It’s good too look to the (near) future, but don’t give up on the things which work great today.

  59. September 1, 2004 by Roger Johansson (Author comment)

    Ruud: Nested tables, spacer GIFs and presentational markup creates bloated, inaccessible and inflexible documents. Building sites that way is definitely not the way to go. The only exception I can think of is if a client refuses to listen to reason and demands that the site displays exactly the same in ancient browsers, like Netscape 4 or IE 4, as it does in modern browsers.

  60. My input is along the lines of comment #2, however it’s not always just going back to fix mistakes, it’s doing things right the first time.

    I work for a large and infamous web consultancy, and as a developer working in a consultancy, the biggest “mistake” I see on a regular basis is the business development people under-scoping and under selling our projects. As a result the development phase is often ridiculously short. We generally have so little time to develop things properly that all of the “nice to have” standards and organization and semantics pretty much go out the window. Great news for the companies that hire us for hundreds of thousands of dollars! Har har har.

    It’s a constant battle deciding between working 60+ hour weeks, and week-ends to build something standards compliant, accessible and really great, or just building something that meets the minimum requirements. I have a feeling I’m not alone here.

  61. I usually don’t add my URL to entries such as these. Even Bravenet, Pliner & Sparklit don’t know my URL, although I use them extensively. But I want you to take a look at the internet web design population. I am one of them. If the internet is just for businesses and college-educated professionals, then the majority of us need to log off, eh? The Drudge Report is hardly filled with slick innovative design, but has managed to become quite famous. The internet is not just for businesses to compete, but for people - ordinary joes and janes - to creatively communicate their own passionate interests. I am plodding along teaching myself what I can while dreaming of the day I can afford a pricey cgi/php capable website, and the chance to attend classes to learn what I cannot teach myself. While looking up the window.open() tag to refresh myself on applying attributes to avoid yet another javascript in my head (literally), and not even remembering if window.open is a tag or a script, I learn that opening new windows is a taboo, target blank is being phased out, and window.open is not fully accessible. And just how many things are 100% accessible in this ever changing browser world? Standards may be written, but isn’t it only recently that Netscape finally displays more of them? Web etiquette is fine and dandy, but it seems to me that the majority of these changes (which eventually renders tags such as target blank inoperable) are geared toward ridding the internet of goobers such as myself, and forcing us to turn it all into commerce. Buy the php, cgi scripts. Buy the web page templates. Buy the js scripts. Buy the css scripts. Make them harder to write, easier to buy. That’s the ticket. And who will own the internet? Just gripin’. I am extremely happy to have found your site and will soon have consumed every page. Thankyou!

  62. For my porn galleries I do not need valid CSS and xhtml but I will give my best to fix that all now after I read that article.

  63. Hi Guys,

    What the problem, if i often use “” Tags?

    Kann you please send me an e-mail explaining that?

    thank you!



  64. Damn.

    I thought you were encoding the HTML-Tags.

    I ment “span”-Tags.

  65. September 6, 2004 by Roger Johansson (Author comment)

    Sina: span elements aren’t always bad. It depends on how you use them. They are “bad” when you use them to mark up something that is more semantically correct to mark up with another HTML element. An example is using <span class="heading2">heading</span> instead of <h2>heading</h2>.

  66. Really, some of the ignorant comments here are quite surprising, especially Vilx (#31).

    Tables within tables are easier to code & understand semantically. Especally with PHP

    I don’t know about you, but I am a PHP developer. I would by far rather do a single div tag between all of my nested if/then/else, for/foreach/while, and case statements then have to worry about properly closing tables and their tr’s and td’s, especially complicated ones with colspans/rowspans. Even when I have to do this to output tabular data, it is still a royal pain in the rear. As for the size difference for tables vs. divs, you do save bites of code using the divs, since div is a shorter word than table, and you dont have to worry about adding tr’s. The size of the CSS file is irrelevant because it gets cached.

    There’s just a lot of things you simply cannot do with table based layouts that CSS can do and the reverse isn’t necessarily true (CSS, exactly as written in the W3C standards — not the IE standard, can do everything any table based layout can do). For a client I once did a project for, the password protected areas of the site had a basic 2 column layout with all of the navigation in the narrow left column and the content in the right column and a header with their logo running all the way across the top. I wanted the login form to be centered on the page, not centered in the area not taken up by the navigation column. Rather than worry about forcing PHP to generate or not generate colspans, I had a simple piece of CSS. The navigational div, along with the navigation links, only displayed once a user successfully logged in and the following CSS controlled the display:

    div#menu { float: right; width: 140px } div#menu+div#body { margin-left: 150px }

    I’ll be the last person to say that CSS support is perfect. But when I can develop brand new designs for my dynamic sites live and online thanks to alternate style sheets and a built-in CSS switcher in my browser without touching a lick of HTML or PHP code and without replicating the entire site, database, etc. on a test server… well, I won’t be going back to table based designs unless I absolutely have to.

  67. Excellent overview! I like looking into the “view source” myself. It tells a lot of the person who created the site, particularly his experience and expertise.

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.