Re: Why can I not make it work right?

On Mon, 14 Apr 2008 12:21:47 GMT, "Beauregard T. Shagnasty"
<a.nony.mous (AT) example (DOT) invalid> wrote:

richard wrote:

Ok so like what the sam hell is the trick here to get a division to
float where I want it to?

div class="bigbox"
<div class="row1">Artist</div
<div class="row2a">Name</div
<div class="row2b">Label</div
/div

This looks like tabular data to me.

Where is it written that tabular data MUST be displayed in tables?
I feel that divisions have more flexibility and I can control the
cells a bit more. I may want to present other information and using a
table would be to cumbersome. Using divisions eliminates the need of
colspan and rowspan.

On this part of my project, I feel that divisions are more
appropriate.

On Apr 14, 10:48 am, richard <i.do.... (AT) ca (DOT) re> wrote:

This looks like tabular data to me.
Where is it written that tabular data MUST be displayed in tables?

Now what would the response have been had it NOT been tabular data and
someone said "where is it written that non tabular date can NOT be in
a table...."

Oh they joys of the web....

On 14 Apr, 15:48, richard <i.do.... (AT) ca (DOT) re> wrote:

On this part of my project, I feel that divisions are more
appropriate.

You don't have any data on this page yet, just a single header (row?).

Potentially, this data (when you add it) is about as tabular as it
gets - if you want to work with it as a long list of recordings, each
of which has an identical set of a few properties. Now that's a good
candidate for <table>

OTOH, your intention might be (still thinking about the "data" that
the page contains) that it's more of a list of short encyclopedia-
style entries for each recording, where the property model of each one
is more complex, has entries that are individually longer, and that
varies more in conceptual structure between rows. In that case, a
sequence of nested sequences of <div> (inside a wrapper <div> for each
recording) is indeed more appropriate.


Then there's the practical limitation of what's actually
implementable. HTML is a a language for marking up pages, it's not
intended to be the one true data representation language. If one page
view of the data is more or less "table like" than another page
viewing the same data, then you can quite reasonably switch between
<div> or <table> markup. You should code the HTML to represent a "pure
data" view of a page and let the CSS worry about the presentation, but
this doesn't mean that different conceptual views onto the same
_underlying_ data can't be based on a different data model that's only
relevant to one page's use of it.