Re: Toward Graceful Deployment of Tables

Luke ~{B7?M~} (ylu@ccwf.cc.utexas.edu)
Mon, 13 Mar 1995 22:51:35 -0600 (CST)

On Mon, 13 Mar 1995, Dan Connolly wrote:
> This is a copy of:
> http://www.w3.org/hypertext/WWW/MarkUp/table-deployment.html
>
> But documents with table markup represent a potential interoperability
> problem, and a potential support burden for information providers.
>
> For example, there is a significant installed base of users who access
> the web via the lynx browser on "shell accounts." Table markup will not
> be interpreted reliably by this installed base.

Surprisingly, the compatibility problem between browsers without table
support (eg., the lynx) and browser with table support (eg., Mozilla 1.1)
can be trivially solved in most common cases, without any negotiation hack,
given browsers are behaved in a friendly way -- ignore unrecognized tags at
the low end and tolerate redundant tags at the high end (the html spec.
section 2.2 on undefined tags makes sense here -- strict SGML conforming on
browser part is a PITA. BTW, I am all for strict conforming in editing and
validation part).

Working examples: http://www.utexas.edu/~lyl/ and
http://louie.cc.utexas.edu:8008/cgi-bin/wgc

Try them with Mozilla 1.1, Mozilla 1.0N and lynx -- table and pre and
others can coexist nicely. The real problem is actually different levels
of implementation of the same table tags. e.g., Mosaic X11 2.5 would
render above pages useless because markups are not allowed in table cells
-- brain-dead if you ask me, I would rather send a imagemap of a table with
alt in pre. Lesson: half-baked implementation is worse than nothing -- and
can NOT be solved by the approaches proposed by Dan.

In most cases, page layout compatibility problems like image position,
table etc. can be solved by DOIT(TM) -- Duplication Of Ignorable (layout)
Tags :-) if the page author understand the concept of loose (vs.
strict/static) page layout in HTML.

Much tougher compatibility problems arise in functional compatibilities
such as image (formats -- partly solved by accept header) and imagemaps,
and especially, form capabilities -- negotiation is really needed here for
different input/selection method, since certain input method such as
SCRIBBLE is not possible for certain browsers, eg., lynx. an
Accept-Input-Methods header might be necessary...

An observation: this group seems to devote too much time to page (logical
or whatever) layout/presentation part of HTML, which is a direct derivative
of SGML; too little time to user interaction part of HTML as a high level
UIDL (user interface description language) which is becoming more and more
important in WWW applications...

__Luke

--
Luke Y. Lu
mailto:ylu@mail.utexas.edu/
http://www.utexas.edu/~lyl/