Re: Converting Centered Table Rows to Divs/CSS

by "Rod Hutson" <rbhutson(at)ieee.org>

 Date:  Sat, 19 Jan 2002 20:48:32 -0700
 To:  <hwg-style(at)hwg.org>
 Cc:  <davida51(at)swbell.net>, "talk2perry" <talk2perry(at)oaktreeweb.com>
 References:  pcrbhh swbell pcrbhh2 ibm23gg279
  todo: View Thread, Original
talk2perry,

I can appreciate your uncertainty over an effort to replace a perfectly
useful and easy to understand method of placing elements on a page, using
tables, with something "new" like CSS - its like jumping out of a perfectly
good airplane and hoping your newly packed 'chute opens before you hit the
ground.

>From my perspective, tables are great - they've allowed me to "get the job
done" for the past five years of webpage buildling - but they don't allow me
to efficiently and practically place an object just anywhere on a screen...
I'm limited to the grid size of the table, and my stamina in designing and
maintaining them.

Tables don't address the problem of presentation using new options to screen
display: audio, braille, WAP, and so on.  This is no big deal today, but
later this year, its going to be a HUGE deal for government-funded
web-masters in the USA.  Accessibility is about to become a major driving
force on the 'Net.

Tables are complex and easily get out of hand on a complicated (ie current
vogue) layout page - if you don't obsessively document table rows and
columns, sometimes down to the cell level, it can be like maintaining the
spaghetti code of old BASIC programs a few months later... even the author
of the original HTML will struggle with adding a new element or re-locating
an existing one.

Tables in some versions of Netscape don't inherit their styles (fonts,
colors, etc) as they're supposed to, adding to the maintenence complexity in
requiring that each cell have its style re-defined individually, making your
code lengthy and ugly and REALLY cluttered.  Subsequent changes to preferred
font or colors forces a lot of rework at the page level.

But my main argument for not using tables to enable layout is that they're
tables, not layout tools.  They were intended to provide a means of
presenting tabluar data via the web, back when the web was a scientist's
communication medium.  Their use as a layout tool was a subsequent hack to
provide restless designers a little control over element positioning in the
old top-to-bottom oriented HTML.  They were a stopgap when there were no
other options.  I can use a hammer to cut wood if necessary, but after
somebody gives me a saw, I quickly figure out that the hammer was pretty
crude and slow - it still works, but I prefer the saw.

And this, I believe is the crux of the issue.  Today's current
standards-compliant (well, almost compliant) browser versions no longer
require this hack - the proper means of laying out your page is finally
available, allowing you to position an element ANYWHERE on (or off) the page
that you want, with far more accuracy and deliberation than tables ever
could.  Its time to abandon the hack and get back to coding with the proper
tools instead of spending all afternoon trying to force-fit a layout into a
tabular arrangement.

Yeah, I know - Homesite and other HTML coding tools provide extremely
powerful search-and-replace engines, including decent grep/AWK/SED -like
macro languages.  But wouldn't you rather work on just one style sheet for
your whole website, than worry about if the search-replace effort caught all
the pages in all the subdirectories, and "do I have to spend all night
spot-checking the entire website for snafu's"?

You can start using CSS now, or you can do it later.  If you are a
web-professional, I'd recommend you start learning now, because in two years
you'll be disadvantaged compared to those who have by then mastered CSS and
are working on other tools that will be optimized for integration into
CSS-based pages.

I prefer to start changing now, so I can "get the job done" today, and get
it done again in six months when the design has been modified.  And I'll
continue to use tables to present tabular data as necessary.  At least,
that's how I see this issue...
Rod

HWG hwg-style mailing list archives, maintained by Webmasters @ IWA