Re: Any browser? table

On Sat, 25 Apr 1998, Nir Dagan wrote:

> Reference number 6 in the WAI authoring
> guidelines "Any browser table" is somewhat
> misleading.

> It recommends to use invalid structure
> in order to achieve backward compatibility
> with non-table browsers.
..
> On the other hand, article number 29 (Flavell) also discusses
> invalid markup, but has the appropriate warnings

Thank you for making this point.  I don't know of a method that is
sure to work with all browsers.

The article to which you refer, involves a combination of techniques,
one of which (the use of H6 markups at a point that is both
syntactically invalid and has no apparent semantic purpose as a
header) seems to me to be uncalled-for.  If this one trick were to be
removed, it's the same technique as the no-break space stuffing
technique, described in McCandlish's EFF page (ref 12).

I should like to stress that my article was aimed at compatibility
with old browsers, and with Lynx, and was not written specifically as
a contribution to web accessibility in the sense of the WAI.  I'm of
course glad if you can get something useful out of it!

The combination of PRE with TABLE (invalid syntax) has worked with a
remarkably wide range of _older_ browsers, as well as with Lynx. 
However, it stopped working with some recent versions of Lynx.  As
invalid syntax it certainly can't be recommended to the general
authoring community without strong reservations; as you say, I tried
to do that in my paper.

There is a technique using the HTML3.0 TAB tag, described in the Lynx
documentation and mentioned in my article.  However, as far as I know,
it has no useful effect on any other non-table browser, and it can
cause problems on those few browsers that try to implement both TABLE
and TAB.  And you would need a custom DTD to validate it, unless you
are going to confine yourself to markup that fits the HTML3.0 draft
DTD (not recommended). 

Originally, I was guided away from the non-breaking space, both by the
fact that some older browsers didn't support   and/or    and
by the fact that the HTML3.0 proposal implied that multiple
non-breaking spaces should be compressed. 

Nowadays, all recent browser/versions will implement   and  
, and the great majority, maybe even all, will treat multiple no-break
spaces as uncompressible. 

It seems, therefore, that in a context where the reader population
could be expected to be using fairly recent browser/versions, the best
way to deal with non-table browsers (sc. Lynx) would be the "no-break
space stuffing" technique. 

There is in fact no need to use the representations   or   
unless you want to:  for those authors who have the expertise to
handle it[*], the spaces can be inserted as genuine no-break
characters - an octet of value 160 decimal (if the charset is an
iso-8859-x etc.).


In the context of this discussion, I think that the no-break space
stuffing technique is probably the one to recommend.   Provided, of
course, that we are dealing with bona fide "tabular data".


The final point that I would make is the one about tables used for
layout.  This will be rightly discouraged by the guidelines.  But
it's possible to design table "layout" in a way that deliberately
falls into a quite different "layout" on Lynx.  Where this approach
fails, though, is with a text-mode browser which implements tables,
such as emacs-w3, which can produce ludicrous results when the browser
is presented with tables-for-layout pages.


[*]This may be a dangerous technique for those who are performing
cross-platform transfers when publishing their web pages.  Once the
page is safely on the server, HTTP is a guaranteed 8-bit protocol, so
nothing could go wrong.

Hope that was useful.

Received on Friday, 24 April 1998 15:21:54 UTC