[paulanthony]

The question is how. Anyone built anything like an image gallery with 3 image rows with 5 image columns..using pure CSS. Or used ASP.NET without touching tables. I do agree that getting rid of tables is the way to go...but just wonder on the practicalities of doing it within web applications. For example look at this forum...built in tables..But is it really tabular data? I can think of countless other application that would require screen calculations to create absoulte positioned DIV's across the screen. Anyone any thoughts on this?

[cam]

An image gallery with 3 rows and 5 columns is a piece of piss in css - check out floated definition lists. So CSS takes care of the layout, and your server-side code (asp in your case) takes care of populating the layout.

A prime example of what you're getting at (the shortcomings of css for layout) is html forms, which if they are complex enough can be an absolute nightmare - and the 'solutions' for such layouts often include bloated (div-tastic) markup. In such cases it's tempting to use a properly marked up table, but hopefully with the upcoming xforms/webforms tech's and increased support of CSS2 and above (*looks at IE7*) this may get better soon.

Not sure where you'e going with screen calculations + absolute positioned divs though, that sounds uncomfortably like a return to browser,screen-size and god-knows-what-else detection. Care to give some examples of what you mean and we'll do our best to show you how to do what you want without opening that bag of worms

[paulanthony]

Im thinking a Calendar Control situation off the top of my head...I aint seen any forum code implemented like that either.

[cam]

Not sure what you mean by "Calendar Control", but there's been discussions about whether or not calendars are actually tabular data, in which case it would be semantically correct to use a table to store the data (which can then be formatted via css). The argument goes along the lines of "that [the calendar] is a matrix of cells that have a relationship to each other(the days and the numbers)" [quote from css-d], which I happen to agree with.

The fact that eric meyer has an example up on his site (it's from one of the examples in his books), where he uses tables for calendar data (http://www.ericmeyeroncss.com/projects/03/) sways me even more. Of course that's not to say that an entirely non-table calendar isn't possible, but the code required would be far heftier and (imo) semantically incorrect.

[seen.to]

Just finishing up on a pure CSS/XHTML search engine/directory - CSS for layout and PHP/MySQL generating the content.

[Luke Redpath]

Originally Posted by i_am_cam

A prime example of what you're getting at (the shortcomings of css for layout) is html forms, which if they are complex enough can be an absolute nightmare - and the 'solutions' for such layouts often include bloated (div-tastic) markup. In such cases it's tempting to use a properly marked up table, but hopefully with the upcoming xforms/webforms tech's and increased support of CSS2 and above (*looks at IE7*) this may get better soon.

FWIW, standard forms are pretty easy markup/CSS wise (with a bit of tweaking for cross browser)...and I always use the following markup (some attributes ommitted):

<form>

<fieldset>

<label>Name: <input type="text" /></label>
<label>E-mail address: <input type="text" /></label>

</fieldset>

</form>

// etc...

CSS styling is as simple as making LABEL's block elements, and applying position relative:, and then positioning the fields absolutely within the label elements (top: 0, left: however far over to the right you want them).

There is a little bit more to it but thats about the basic principle. No floats, no bloated markup. The markup above forms the basis for my PHP5 library of Form generation classes (with built in submission detection/validation/processing) so making forms becomes much less hassle.

[paulanthony]

Originally Posted by pgo

Come to think of it, marking up a forum with a table could be semantically correct on certain pages - like index pages and the like - since you'll have "Subject" "Poster" "Posts" "Views" and the like...on those pages, tables would be semantically correct as far as I'm concerned.

Could you elaborate on this malarchy for me....I was under the impression that tabular data was (see attachment). Dont get me wrong im not taking a dig, I just think that theres nothing within a forum that constitutes hard tabular data.

[paulanthony]

Oh and I hereby declare that I shall quit whinging and go and do something about it.

[pgo]

Originally Posted by paulanthony

Could you elaborate on this malarchy for me....I was under the impression that tabular data was (see attachment).

Certainly, though I wonder where my post went! I didn't erase it and it seems to have disappeared.

A table is...

Originally Posted by Dictionary.com

An orderly arrangement of data, especially one in which the data are arranged in columns and rows in an essentially rectangular form.

That's a pretty broad definition.

Your standard forum index will have, say for DT..."Forum"..."Posts"..."Threads"..."Last Post". Under these four header cells are four columns and infinite rows, each listing a forum, number of posts for that forum, threads in that forum, and the most recent post in that forum. That's an orderly arrangement of data in columns and rows that are filled with related data. Same goes for listing of threads within a specific forum. It gets less tabular when you get into the individual threads, however.

I'm not saying that a table is appropriate for everything within a forum, but for pages like that - it is appropriate.

[nakedintruder]

Originally Posted by Luke Redpath

CSS styling is as simple as making LABEL's block elements, and applying position relative:, and then positioning the fields absolutely within the label elements (top: 0, left: however far over to the right you want them).

There is a little bit more to it but thats about the basic principle. No floats, no bloated markup.

Ah good man, I hadn't considered that, I was doing it with floats before and having to either take forever on it or have a much longer, less 'quick feeling' registration.

I'll have a try with this.