How do you know what the author desired? The best you can do is make
the notation as easy and as `intuitive' as possible, and hope that
authors make fewer mistakes. But without a table editor, I doubt that
tables in SGML will ever be intuitive. The TEI model (table = row+,
row = cell+, and just two attributes) is probably the best you can do,
all other models (Exoterica, Qwertz, Dave's latest, SoftQuad, CALS)
are progressively harder to get right. Some of then even allow
nonsensical tables that are neverthelesss syntactically correct.
|I'm not calling for a change in the spec here (though I think
|overlapping cells have *great* potential), just a change in the
|wording of the warning.
You'll have to explain. What is the potential for overlapping cells,
especially seeing that you can't just overlap any cell? Only in a few,
*very* non-intuitive, cases, e.g, never in the upper left corner of a
cell.
If you want overlapping elements, then you'll have to provide an
explicit tag for it, so that you can define what it means when two
things overlap, which one is drawn first, what is the operation
performed on the pixels, what happens when you click on it, etc.
|| [...]
|| || ALIGN
|| || This can be one of: LEFT, CENTER, RIGHT, JUSTIFY and CHAR. User
|| || agents may treat Justify as left alignment if they lack support
|| || for text justification. ALIGN=CHAR is used for aligning cell
|| || contents on a particular character. The attribute value for
|| || ALIGN is case insensitive.
|| |
|| |A question that came up wrt CALS, and which I repeat here: how does
|| |one set the gutter width between columns? (I don't have the answer
|| |for CALS, can't see how to do it.) This was desired recently at ORA.
||
|| That's interesting. Why would you want to (apart from aesthetical
|| reasons)?
|
|Readbility, which in typesetting involves the aesthetic. Notice you
|don't have any way to set margins inside columns, which would solve
|the problem a different way (again, a CALS problem too).
If this remark came from anybody else, I'd simply say `stylesheets'.
But coming from Terry, there is probably more behind it. What is it
that you need an explicit gutter for, instead of a CLASS?
(Btw. I proposed a COMPACT attribute on tables, analogous to lists
(see [1] or an updated version [2]); would that solve the problem?)
[1]: <http://www.acl.lanl.gov/HTML_WG/html-wg-95q2.messages/1355.html>
[2]: <http://grid.let.rug.nl/~bert/draft-html-tables-01.txt>
|Scott:
|| One small problem with allowing flow around a CENTERed table si that you
|| have two flow areas, so you have to decide whether to flow horizontally
|| (text goes line by line, each lne with some text left of the table and
|| some text right of the table) or to flow vertically (flowing down the
|| column to the left of the table and then flowing down the column to the
|| right of the table).
|
|I've seen horizontal flow, not sure I've ever seen vertical in this
|case. Bert asserts it's something an experienced typographer would
|reject; I say, look about you, and don't assume the typographer isn't
|taking orders from some "graphic artist."
Let's try another argument: we shouldn't burden the browser writer
with requirements that are difficult to implement and of doubtful
utility anyway.
Btw. the layout that Scott Preece suggested (text block1, figure, text
block 2, allthree on one line) can indeed be handled by Hakon Lie's
proposed style sheet language, but note that this has nothing to do
with flowing text.
|Bert:
||JUSTIFY can be dropped, since it is the same as CENTER, but
||for a full-width table.
|
|Justification implies stretching something out so that it extends
|from margin to margin. Not the same as CENTER; it should stay.
But stretching the table is already handled by the WIDTH attribute,
why do you need JUSTIFY as well? What if the two conflict?
Also, as Chris Tilbury pointed out, ALIGN is already being used for
too many different things (float or not, align horizontally, align
vertically, wrap text or not). Instead of adding another dimension
(stretch or not), we should try to offload things to other attributes.
Bert
--
Bert Bos Alfa-informatica
<bert@let.rug.nl> Rijksuniversiteit Groningen
<http://www.let.rug.nl/~bert/> Postbus 716, NL-9700 AS GRONINGEN