[thelist] HTML tables and Content Management Systems

[John williams]

I don't think you'll find an ideal solution for all situations; you
need to look at what your users are doing with their tables to begin
with. The tabular data needs of, say, a television station's site
aren't going to match well with a science journal's.

I think the table object is a good idea for fairly stable content or
significant quantities of table data, but I think you run the risk of
embedding Excel Lite in your CMS. Especially if you create a seperate
container for a table, like a CSV file or data table in your database
-- you'll have to provide an interface for editing, managing, and
embedding the tables. And when you export the entire article out again
into a different format -- XML, etc -- you'll have to create another
parser for that as well.

> >A few CMS's use a wysiwyg system, often handled by applets or JavaScript.
> >While this makes table creation in the CMS easier, it does little for
> >design consistency or ease of use. Alternatively people can use markup
> >systems like textile. However this is simply switching one markup system
> >for another so is also not ideal.

But the advantage of textile/wikki table syntax is that markup is
highly compact and abbreviated -- the required nine characters to open
and close a table cell become one or two (one for interior cells, two
for edge cells) and naturally enough carriage returns open and close
the rows. The pipes even look like cell borders, so it's intuitive.
There's not much in the way of attributes to change in the code itself
(it's all stylesheet driven), so it's much more difficult for editors
to abuse. And with the highly limited vocabulary of  textile/wikki, it
becomes much easier to edit with regex when you need to convert to a
different markup.

That kind of markup has its faults as well, but I think for infrequent
and/or small tables in your content it's more portable and easier to
explain to an editor or author than a table-management module.