Tableless design, have to or not have to?

I uses css+table+template+include.

Header and footer will be in the included file. So changes to them will be only from one place.

And use limited tables to position the contents.

Use CSS to format.

Plus template is used, but limited.

I have read the threads from this forum, I think many php programmers use this css+table+template+include approach too.

I think this way is easy to read, modify, easy to design (WYSIWYG). It is better than tableless pure CSS, which uses div to totally replace tables.

But I saw many top php OSS went to tableless CSS already.

Is the tableless pure CSS the trend that I have to follow no matter what?

What steps you take from a css+table+template+include php programmer to transfer to pure CSS design?

Any advices on how should I make this transfer? Books, web sites, tutorials?

Thanks!

    Look at cnn.com, nytimes.com, yahoo.com, apple.com, facebook.com, twitter.com, youtube.com: none of them use tables - time to get on the web 2.0 bandwagon and go table-less, granted that you want to code like the top sites do.

      You don't have to follow any trend you don't want to. You can even become a lumberjack for that matter.

      But tables exist for a purpose, and it's not stylistic things like page layout.

      If you want to catch up with the twenty-first century, there should be plenty of resources available from a search, like the one I found some time back the last time I did. Also from the same thread I last posted that link is one from NogDog and another source of material I use fairly often. It's instructive to look at the source of all three pages.

      If you go way overboard with the HTML you can end up with http://www.csszengarden.com/

      Here's the idea: the markup in HTML is to specify what is being marked up. If it's a list, use a list element (you've got a choice of three different kinds). If it's a heading, use a heading. If it's a related set of form fields, they go in a <fieldset> element. If it's a table header or footer or caption, use a <thead>, <tfoot>, or <caption> element while the body can go in a <tbody> and individual table columns can be identified with <col> and <colgroup> elements (and there is a difference between <td> and <th>). Block quotations go in <blockquote> elements and inline quotations go in <q> elements, citations go in <cite> elements, addresses go in <address> elements, and definitions go in <dfn> elements; a pushbutton is a <button> element not an <img>; abbreviations and acronyms have distinct elements; there is a difference between <tt>, <kbd>, <var>, and <code>; <div>s and <span>s are for when there is nothing more appropriate; and none of these specify how they should look, only what they mean. The browser provides defaults so that they're at least usable without additional styling, but you're under no obligation to just accept the defaults.

      Before you can get proficient with CSS you have to make an effort to understand your HTML.

        Lots of good articles at http://alistapart.com.

        And yes, when I am in full control of the HTML, I only use tables for tabular data and depend entirely on CSS for page layout. (Sometimes, however, I am just the server-side cog in the development engine and have to use the tabular layout some client-side cog has developed.)

          coldwerturkey wrote:

          Look at cnn.com, nytimes.com, yahoo.com, apple.com, facebook.com, twitter.com, youtube.com:

          You can add ibm.com, zend.com, nzherald.co.nz, and tvnz.co.nz (which does have table elements - the programme listings for each channel are tables).

            blackhorse;10915642 wrote:

            Thanks!

            Tableless it is.

            Be ready for some learning -- and unlearning. But once you master it, you'll love the ease it provides when you want to change an entire site's visual layout, or perhaps provide a separate layout for mobile devices, and all you have to do is change/add some lines in one CSS file. 🙂

              I think it's all relative to needs.
              I do think that the "form follows function" design approach is always going to be challenged, I do think sites are starting to look WAY too much like each other because of "good programming", but with that said, tables simply became outdated, however, still hold a few tricks that need hacks/JS for css & divs. For example, alot of designers use Divs + CSS + javascript to make columns the same height. If it must be so I would suggest a table instead to eliminate the needs for the JS.

              Some people argue portability between display types (mobile, tv, different monitors) as a reason, other network speeds and download speeds, which are all valid points, but it wont kill you to use a table if you think it makes more sense then lines of code + scripts to be executed.

              on an kind of related subject. I do think new developers (especially ones starting after the Web 2.0 craze) are becoming WAY to dependent on libraries to do anything, especially when it comes to layouts. I do think a more systematic & universal approach is probably the future of web dev, but I think it's also important to not just follow a trend. To be clear though, i dont think tableless design is a "trend", it's here to stay and evolve.

              Hell I remember "reflections" were the golden rule 2 years ago, last year "glass effect" took cover. People try to hard to look cool and lose common sense

                9 days later

                I personally only use table less designs.. Decoupling content from presentation allows more control / maintenance flexibility.

                Not only that, files like external css stylesheets can be cached, where as tables (which are embedded within the html document) cannot. Sure, some may argue that external sheets incur additional HTTP requests, but as far as I'm concerned, an intelligently designed and built website employing Yahoo's best practices can greatly reduce those http requests in other areas (such as using css sprite sheets, merging javascript files where possible, etc..). And if the presentation layer is designed carefully, one should not need many style sheets to achieve the desired look (I usually manage to make use of two; one for the main gui, while the other governs the current page's content layout - This I can improve on for sure).

                The hardest thing about learning css in my experience is that it is a tad tricky at first. I wasn't familiar with the box model, nor what block or inline elements where.. I particularly found floating elements to be the trickiest.. Sometimes I would get the desired results, while at other times, I was left scratching my head. But once you really start to grasp how it all comes together, it is really is quite nice (I wouldn't foresee you going back to tables for layout / presentation purposes anymore). Tables should definitely be left for tabular data.

                  Write a Reply...