Why I don't like tables

From the maintenance point of view (not CSS vs HTML), I don't see the difference between

<p><font ...>text</font></p>

and

<p style="...">text</p>

I understand why you want to avoid extra references to style sheets, though. That sounds like a good reason. Personally, I would still think of a way to group style sheets, but if HTML formatting works better for you, it's cool

J.D.

 

The only big problem with CSS is that you do need to plan ahead a little.
Without, you just go by the line.
Eventually I reduce the size and better organize the page with CSS.

 

so you didnt fancy writing the CSS for that test page then?

......me neither! LOL

Regards J.D
G-E-M

 

Hey, why not. Don't remove the page yet

J.D.

 

no...dont do it man......i can change it much quicker than you can CSS it...and its only a test page !!!

nice offer though


i got a 28K page site that needs some work...LOLOL..teehee

 

Here you go. It's *far* from perfect - it's just a bit less of a mess. Man, you gotta hire somebody to straighten this stuff out.

Take my advice - create a few groups of styles for each of your tables, name the chunks of text you have (phone, address, website, etc.) and rotate styles (automatically, if you want).

J.D.

 

hehe..nice one J.D,
although there are still font-size tags throughout the code?
it doesnt need sorting out,,,,its really easy to organise, and to change.
The parts i need CSS are in CSS, the parts i dont....aren't.
... only 27,999 to go

G-E-M

edit: <<create a few groups of styles for each of your tables>>

thats hard to do when you have no idea whats going in the tables, until the phone rings.One chap phoned and literally started dictating a page of text, about half way through i had to tell him that he had slightly over done it, and we sorted of course.

 

I believe part of the reason was future-proofing. With a good structural markup you can make the same page work on either a web enabled phone or a high resolution computer monitor; each rendering differently, but still delivering the same page, with the content displayed in a meaningful way. If you were to try to achieve that with a nested table layout, you would almost inevitably have to resort to multiple versions of the page. Designing your website using webstandards not only speeds them up (external stylesheets save a LOT of bandwidth), but also future-proofs them.

I still use tables a lot, mainly because my CSS skills just aren't good enough. But, I intend to continue to move towards CSS. Tables are the hardest part It's about the only thing stopping me from going XHTML strict. Anyway, nothing is really wrong with XHTML transitional anyway.

28k static pages - geez - dare I suggest a database might be in order??

 

HTML and CSS work hand in hand to deliver content that can be viewed on different devices:

http://www.w3.org/TR/REC-html40/present/styles.html#h-14.2.4
http://www.w3.org/TR/CSS21/media.html

The idea is that you can advise the browser to pick the right style for the right device (e.g. you can use {display: none} for elements that are not supposed to be visible on a PDA).

Tables and CSS aren't really one vs. another

XHTML is XML and as such allows you to use more than one markup language (e.g. you can use MathML inside XHTML). Unless that is exactly what you are looking for, you may want to stick with HTML strict for now.

Some mobile browsers work only with XHTML, often XHTML Basic. BTW, XHTML Basic doesn't support many HTML formatting elements (e.g. <b>, <i>, etc). External stylesheets is the only way to format your pages in XHTML Basic.

Keep in mind that *all* websites now serve XHTML as HTML (content-type: text/html). If served as XHTML/XML (application/xhtml+xml), IE will not even render the content. FF and Opera will, although with some differences.

One more thing - XML isn't as forgiving as HTML. A missing tag will result in the entire document invalidated. FF will display an error, Opera will render the document, but will append the XML document tree at the end.

J.D.

 

I didn't say they were; it's just that because I'm not good enough at CSS, I find it quite hard to get decent layout working using divs only.

In my understanding (mainly garnered from reading Jeffrey Zeldman's book on the matter), people should attempt to at least update webpages to XHTML Transitional. The fact that it is more strict is a good thing in my opinion. Browsers will continue to offer backwards compatability / quirks mode for those sites that haven't made the move, but in my opinion it is always best to design according to the best standards available (within your capability) and basic HTML isn't that.

I'm no expert on the matter, but I like to advance my knowledge rather than stubbornly cling to relics of the past. I've managed to get a few websites put together with XHTML Transitional now and I've been very happy with the results! They're easy to maintain, have nice clean markup, load quickly and render appropriately on any number of browsers!

 

I find this as a bit of a strange phenomenon that many people treat DIV-based design as a synonym for CSS. It's like one of those urban legends

I doubt it - that's the nature of XML, to be DTD-compliant, no compromises. The only reason XHTML websites render in many browsers is because you serve the content as text/html. Try swtching to application/xhtml+xml and, say, remove one of </p>'s and see what happens in FF or Opera (IE won't display this at all).

HTML 4.01 is almost as strict (if you use the strict DOCTYPE), but still forgiving for non-conforming browsers. I cannot imagine somebody publishing a website with a note - "only good in FF (IE/Opera/etc)".

then you want to learn CSS

I like XHTML - I did a couple of XSL-based websites and XHTML was a natural choice for those projects. The point here, I guess, is that many people see HTML, XHTML and CSS as three different things. They aren't - XHTML is hailed as a successor of HTML and CSS works with both of them equally well.

Personally, though, until there's appropriate browser support, I will still use strict HTML and CSS for most of the projects. The last thing I want to see is people not being able to see the website just because they use a non-conforming browser.

J.D.

 

I still use table,,,but intergrate with many css

 

I'm not suggesting they are - is that the impression you get from my post??

The term 'Div-based Design' seems odd though.. In my understanding divs are structural; any 'designing' is done in CSS.

I'm just saying that I would like to move to divs from a structural markup point of view, but because my CSS skills aren't quite good enough, I have trouble controlling the layout. As a result, I tend to revert to a table layout instead as that is a lot easier for a grid based layout. Clear now?

But I'm quite happy serving it as text/html - from my fount of wisdom and knowledge "Designing with Web Standards", this is the suggested way to serve XHTML. I've never tried serving it as xhtml+xml - I've never had a reason.. I thought if I serve a page with an XHTML Transitional DTD, this would trigger full on Standards mode in most modern browsers.

What you describe doesn't sound like a non-compliant browser - it sounds like a non-compliant programmer

well, they are three different things.. XHTML isn't HTML and XHTML isn't CSS. Just like Adobe Photoshop 1 isn't the same thing as Photoshop CS. I'm not sure who suggested CSS doesn't work with either XHTML or HTML - I sure didn't.

For XHTML Transitional, the browser support seems pretty darned good to me. Not only can things render nicely in old fashioned browsers of the v 4.0 era, but they can also be handled nicely by modern mobile device browsers. A browser not being able to handle a missing </p> tag is NOT non-conforming - it's in fact fully compliant. It's the programmer who needs to conform.

NOW, I thought the original point was to discuss tables vs divs. In that regard, my question is whether or not using tables will enable all browsers to view the page? Would a typical nested table layout manage to render ok on a PDA / mobile phone? I really don't care whether people use tables or not. I do care about making sites as accessible as possible though and if getting rid of some tables will help do that, then that is the direction I want to be heading.

 

This is the point many people miss about XHTML - its primary purpose is not strictness (strictness is rather a result of it being XML), but to be able to mix up different XML-based markup languages. For example, you can have XML records and HTML in the same XHTML document and you can sort records automatically using XSL transformation and render the sorted data as HTML.

In other words, everybody who's using XHTML now is just using a small subset of XHTML - the HTML portion of the standard. XHTML is based of HTML 4.01 (actually, there's no even separate spec for XHTML describing elements - instead, the spec simply states how to interpret HTML 4.01 in order to make it into XHTML). Here, see it for yourself:

http://www.w3.org/TR/xhtml1/

Anyway, we are off the main topic of this thread - tables and CSS.

My point was that many people use these three in a sentence that has some form of "HTML/XHTML or CSS" and these three should be used together. I think we are talking about the same thing, though.

</p> is optional in HTML 4.01, just as many other tags. It is not a mistake to omit one in HTML - it's a matter of style. I'm not saying it's good, don't reply on that - I personally always balance tags, but that's how the standard was for many, many years.

As for the programmer, it's easy to make a mistake. See for yourself - this page on your website isn't XHTML compliant:

http://www.travellerspoint.com/helpersearch.cfm

Basically, what you serve is well-formed HTML (BTW, very well-formed).

Yes, most PDA browsers will handle tables correctly. Opera has a really nice feature "Small Screen Rendering". If you press Shift-F11 in Opera you will see how it works. I think it's quite impressive:

http://www.opera.com/products/mobile/smallscreen/

Mobile browsers support a subset of tables (e.g. XHTML Basic supports these table elements: caption, table, td, th, tr).

Tables are implemented better than DIV's in *all* browsers and better compatible between each other. The table element exists in all specs - HTML, XHTML and CSS. It's not going anywere, trust me

J.D.

 

Of the original topic <TABLE> vs. <DIV> I use tables for backward compatibility of browsers.
www.arcadegames.co.uk
Do a view source, if the source is laid out well and commented it is easy to read and easy to maintain like all code. I currently only use <DIV>s on my stats pages
www.domainhub.co.uk/stats/2005-01_webstats.html
as html 4 provides very easy to use formatting, in addition to tables. I will still use tables in the future but <DIV>s and CSS will make life much easier when they are established in 99% of browsers.
<DIV>s and CSS are easy do a couple of hours of reading and experimenting, it will be worth it.

 

Ok, I think I can summarize what I heard so far about tables. Somehow two different things got mixed up - HTML tables and HTML table-specific formatting. Amazingly, in order to avoid the latter, people are trying to ditch the former.

Let me say this loud and clear - div's will never replace tables. It's the original HTML formatting (i.e. bgcolor, cellspacing, cellpadding, valign, border, etc) that needs to be put to rest.

Here's a simple example for all of those who strongly believe in the power of div's. Try to put two 50% div's side-by-side and then try to make them of even height regardless of their content. Now do this with a table and compare the effort and the result. The table will always stay formatted as expected and div's will often be of different height because one would have more data than another.

Add there half-implemented things like colgroup's, col's (even at this stage they are great when combined with CSS), tbody/thead/tfoot and CSS support for tables and you will see my point.

J.D.

 

I've just started using CSS.... and I like it... but here comes the worst part of it

As far as i know... there is no software to do with css what dreamweaver can do with tables... so i write down the html and css by myself...

But I prefer divs and css for the reason that the ouput is smaller...

 

in css you can specify height this way

div {
height: 100px;
min-height: 100px; // Firefox, NS...
}

that way it will remain to 100px if the content does not exceed that.


if you really wanna do it reglardless of their content... you must put a div that has the 2 divs within it and put the height of the two divs at 100%

Haven't tested it but it should work

 

It's true, most WYSIWYG editors don't do a good job when it comes to editing dynamic pages (e.g. when asp/jsp/php/etc include part of <head>, including CSS links). I got used to it by now and most of the time I'm just flipping between the editor and 3-4 broswsers (IE, FF, etc) to see how it *actually* looks.

J.D.

 

Try it The problem is not only in that div's are block-level elements and Opera is the only one who implements "display: inline-block", which would put two div's on the same line, but also in that div's are not related to each other (compared to td's) and setting "height: 100%" is not working well all the time. Here's a small example - it will work as expected only in Opera:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head><title>DIV Test</title><style type="text/css">
div {line-height: 1.5em; height: 2em;}
div.c1 {border: 1px solid green; height: 200px; width: 400px; margin: 0; }
div.d1 {border: 1px solid red; padding 2px; width: 40%; display: inline-block; height: 100%;}
div.d2 {border: 1px solid blue; padding 2px; width: 40%; display: inline-block; height: 100%;}
</style></head><body>
<div class="c1">
<div class="d1">d1</div><div class="d2">d2</div>
</div>
</body></html>

Code (markup):

If you make these div's inline (display: inline) to put the on the same line, they will collapse because width doesn't apply to inlines. You can resort to floats or absolutely-positioned elements, but that's another can of worms. Like I said - compare this to a table and think if it's worth the effort

J.D.