decloak logo
Cart cart | sign out  
css versus tables
 css vs tables: round I. 
    1. benefits to css
 
    2. is full css faster
 
    3. Return on
Investment
 
 
    4. Long Run
Maintenance
 
 
    5. w3c standards
are useless
 
 
    6. structure
and content
 
 
 
 css vs tables round II. 
    7. point:
        tables are for
       tabular data...

     counter point:
       yes, but tables
       make up
       databases.
       Duhhh!!!








    8. Hey Stupid
 
    9. Bandwidth Savings
 
    10. accessibility and
     $4000 wheelchair
     ramps
 
 
 
    11. Spend Time
Learning
 
 
    12. Captured
CSS Flagship
 
 
    13. Selling your
product
 
 
    14. May work well
 
    15. Standards
Merry Go Round
 
 
    16. Extremists
Update
 
 
 
 
  
 
    Using FULL CSS makes surfing FASTER
  1. MYTH. FALSE. UNPROVEN. (and if not a myth, how much faster?) Has this statement above actually been proven true on a variety of websites? Has there actually been a true performance test done? As far as one can tell, users cannot see, or notice, a bit of difference between a full CSS website and nested tables website. What about the size of that initial .css file? That's going to be bigger; and then if you have one main .css file, who says they are going to visit enough pages on your website anyway to really enjoy the benefits of having that extra large .css file download initially. Don't you want that first page to be fast?
    ...50% of bandwidth is Images anyway. Then there is 25% for the original authored content, 5% for the JavaScript, 5% for the CSS page, and 5% for all the other HTML like anchor tags, body, head, etc..... In the end, there is not much left to reduce in the first place...

    HTML Web Page Bandwidth Breakdown Pie Chart



    There are many mis-informed people that think that CSS-P reduces the web page's size dramatically for a large table using CSS. The clue here is "large table". .Let's see 100 to 500 or more rows.
    POINT:
      " Using CSS-P would make a 500 row table display faster."


    COUNTER POINT:

      "Have you ever actually written the CSS-P for a 500 row table? It's incredibly large to say the least. Next, the user would have to download the CSS-P stylesheet for a 500 row table and that the CSS-P stylesheet could easily be larger in size than the data in 500 row table in the first place. You could easily be asking the user to essentially download your CSS-P 500 row table web page twice!!"


    DOSE of REALITY:
      What good is it to say that CSS-P is faster than tables when you can't even make or maintain a CSS-P table in the first place? That's even worse than saying, "The fastest way down this mountain is to jump off the edge of that cliff over there." CSS-P, realistically, CANNOT and SHOULD NOT be used to make a 10, 20, 100, or 500 row table in the first place as you couldn't even maintain it, or for that matter, even build a 500 row table in CSS-P anyway. So CSS-P loses on the very point it trumpets to the world: 'its so-called advantage of speed over tables'. Second, CSS-P loses again on another point (that's just as important), maintainability."


    CSS-P elitists say that tables are good for tabular data, but then immediately say that CSS-P displays large tables faster while forgetting that it's a nightmare to write a 100 row table with CSS-P. The people who do a lot of the CSS-P "talking" rarely ever do a lot of "doing" . Talking and Doing are 2 different things.

    Additionally, how many people sit and read 100 rows of search results even on Google or Yahoo? As you can see, these numbers and reasoning are quite twisted.

    Even if it did display faster, will users be able to notice? Do users actually see a bit of difference in ESPN or Wired when compared to <table> website versus so-called ground breaking pioneer websites for the fanatical pro-CSS crowd? Just as important, Display faster doesn't always mean Download faster.

    CSS Elitists are quick to point out,
    "The css page is only loaded with the first page, after that, it's faster."
    Ok, three points to make below:

    POINT ONE: CSS-P immediately lose on the first page, of which is the most important page to a visitor's first impression, especially for advertising campaigns as well as 15 minutes of fame via the "bring down the server" Slash Dot link. Ok, it's not as bad a loading a FLASH intro movie like you see on some sites, but we are comparing this to tables with css as opposed to just using CSS-P and no tables.

    POINT TWO: CSS-P on the following pages where the CSS style sheet has already been loaded is virtually the same and unnoticeable to the user when compared to other non-CSS-P sites that use table and css. Oh, but CSS-P will talk about total bandwidth saving per month. Ok, click here to see a break down and R.O.I. of their so-called total bandwidth savings.

    POINT THREE: Subsequent Pages after the first page only SEEM faster only because visitors had to wait longer for the initial page with it's larger css-p stylesheet to load in the first place as compared to the subsequent pages.

    POINT FOUR: One forgets that many times, a lot of bandwidth is in the graphics and images, not the HTML code. Thus, it's images (.gifs and .jpg) that can take up 50% or more of the bandwidth anyway.

    Then there is the content itself, 25% at least! As why would people visit that page anyway if there was no original content. And then out of the 25% left there is the HTML, of which some of it is the anchor tags, style tags, head and body tags. (Anchor tags can take up a lot on clickable lists like search results.) And then there is the JavaScript (~5-10%) and then the CSS style sheet (~5-10%). As you can see, table tags don't make up a large percentage of the total bandwidth. Depending upon the type of page, 5-15% is only left for table tags in the first place.

    So, what's the savings? Half the bandwidth on 5-10% of the total bandwidth is 2.5 - 5% savings...MAX!!! Wow, lots of savings there!!! That's, TWO-POINT-FIVE to FIVE percent, not 50%...that's not a misprint.


    CSS-P = "Workaround and Hack City" = Pain in the neck
  2. CSS-P "workarounds" for cross-browser support will also cause a full CSS page to load SLOWER because you have all this extra browser-detection-JavaScript to write as well.

    Then they don't mention about all the "extra" CSS stylesheets to write because a single stylesheet won't work for multiple browsers. So you might end up having DOUBLE or TRIPLE the number of stylesheets to write and also maintain. Oh, but wait, I though we were talking about pages that load faster of which is becoming more of a myth.

    But wait, one more thing, you should forget about Netscape 4.x browsers of which people STILL use. And what about accessibility? Ha! How about getting it to look decent on the Apple Macintosh first? Double Ha ha!

    Fix one thing with a CSS-P website for this browser and another thing breaks on a different browser.


    So let's see. You have more JavaScript to write and now you double or triple the number of CSS pages you have to support. Great! That will increase performance. That is, for the person who has to maintain a full CSS site will have to INCREASE their PERFORMANCE to keep it up and running.


 
flush lines that auto stretch vertically and horizontally
 
terms of use | privacy policy
copyright © 2003 - decloak, inc. all rights reserved