Re: Sightly OT: Design Questions

From: Alfredo Delgado

But how else should it logically go together other than how it looks on

the

screen?  HTML is presentation level, not transmission level.  If you want

to

send the data to the client completely presentation-agnostic, the best

thing

would be to send it as pure XML and then use XSLT to transform it on the
fly.

I'm not against that but IE has a hard enough time with XHTML and CSS so
one step at a time :) As you know you can apply different style sheets
to the same XHTML. This allows your content, which may include tabular
data presented in an XHMTL table, to be positioned according to how you
want it to appear on the medium at hand -- screen, paper, text to speech
reader, iWidget that hasn't been released yet.

You can apply different style sheets to tables just as easily as XHTML.  You
can position tables quite easily if that's your desire.

Also, the entire "one-data-stream-fits-all" concept has some serious
drawbacks.  There's a definite limit to how much "soft-coding" can be done
for alternate devices: at a certain point you have to completely reformat
the data anyway.  There's no way you can send the same data for a
full-screen browser and a cell phone (not without wasting a LOT of bandwidth
for the cell phone).

But if you think about it, a typical business application is all about
tabular data.  A customer information screen is a table of field names

and

values.  An order history screen is a table showing columns of data from
orders.

With a few exceptions, business data is tabular in nature.

Relational data is represented in tables so there's no argument there.
However, a web application involves a user interface if merely to throw
a logo into it for that custom value feeling. Your client's logo and the
user interface elements are independent objects that do not relate to
the data you're displaying in a table.

Maybe they do, maybe they don't.  Maybe I want my banner logo to define the
width of the data below.  Maybe I want to specifically frame my data, with a
nice copyright at the bottom.  All of that can be done using tables very
easily.  I'm sure it can be done with DIVs, too, but -- and here's the real
clincher for me -- it's REALLY EASY with table.

They do not belong in a nested
structure intertwined with the business data.

With respect: oh poo.  <grin>  They belong wherever I want them.  Logos
often contain important business information (this is especially true in
multi-company or multi-tenant systems, where the logo helps to identify who
is logged in and how).

Since business data is at
the heart of the page in a tabular format why would you want to hack
your way through a sea of <tr><td></td></tr> tags just to get to the
dressing on the sides? Templates can quickly get unnecessarily complex
and difficult to maintain if the page is a series of interdependent
table cells.

Here's the fun part.

First, the only person who sees the actual HTML is me.  I'm not sure what
you mean by "hacking through", but it's pretty simple to create a frame of
HTML that contains things like logos and navigation and then plug in the
rest.

Second, "a sea" of tr/td is a gross over-statement.  It's rare to have a
requirement for more than three levels of nesting.  One is typically for
your overall frame, two is for basic divisions in the content, three is for
the actual tabular data.  This is really no more complex than a bunch of
DIVs.

Three, who uses templates?  With JSPs there is no template.  I design my
pages in HTML, plug in data where needed, and I'm done.  And with the
various server-side include options, it's REALLY easy to create a basic look
and feel using header and footer fragments, and then plug in any amount of
data at runtime.

I use this extensively in PSC/400.  You should see how easy it is to create
an application that will run in a full screen browser, and then with a
simple runtime switch make it run in a handheld warehouse scanner.  (It's
actually very cool to see them running what is essentially a 5250
application in a device attached to their wrist <grin>).

Anyway, I'm not saying DIVs are wrong.  They're a powerful tool but just not
necessarily required for everyone.  There's nothing intrinsically better
about DIVs and it's another thing someone has to learn.  Tables aren't
perfect either, but if you know them and are comfortable with them, you can
design perfectly functional web pages, and my really point is that,
especially in web design, KISS rules...

Joe