lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LYNX-DEV Tables in Lynx ...


From: David Woolley
Subject: Re: LYNX-DEV Tables in Lynx ...
Date: Wed, 1 Apr 1998 23:05:11 +0100 (BST)

> Perhaps we could offer "hint" attributes to tables writers, what should
> lynx try to do with it?  It wouldn't fit the present DTDs -- but it seems 
> to be how NS and MS got people willing to use some of their features.
> Last I checked, misunderstood tags or attributes are still supposed to
> be ignored completely, as if they're not present.
> 

This is the role of style sheets (and, in my view, it is more important
for Lynx to support these than tables, as they are the means by which 
it may be possible to get people back into separating physical and
logical aspects, so that Lynx can work on an accurate logical model,
rather than one contrived to force a physical result).

> We could design lynx' usable ways of handling tables and allow web authors 
> to optionally tag their tables as to which kind they are.  The user could 
> have a key to select a default rendering type.
> 
> Oh, for completeness, some possible responses I see are:
> indicator:
>   1. nothing - rely on available markup or replacements from below
>   2. strings from somewhere, "(begin table)" "(end table)"
>   3. HR at top and bottom.
>   4. <TABLE></TABLE> = <p></p> 

TABLE probably terminates P, and tables can certainly contain things which 
are not %inline.  I think TABLE is currently implemented as <DIV></DIV>
when not in <PRE>.

>   5. capture everything between <TABLE></TABLE> to a buffer, leaving
>      behind a [TABLE] link.  User can launch a selected helper app to 
>      deal with it, or ask lynx to attempt further rendering.

Gets messy because of interactions with FORM, which is quite likely.

>   2. TR = BR (line break)

Approximately current implementation.

> 
>   2. Parse table as a list type
>    a. DL type - <TABLE></TABLE>=<DL></DL>, TH = DT, TD = DD.  

The implications of the HTML 4.0 spec are that TH should be deferred
and rendered in front of each relevant TD, but not in the heading.
There is a lot of discussion in both HTML 4.0 and CSS2.

>       The main problem I see here is strictly speaking 
>           <dl><dd>bla bla bla<dd>yep indeedy<dd>that's what I said</dl>
>       is *not* legal - there should have been pairs of DT's and DD's.
> 
> SHML lawyers please comment, Thanks In Advance :)

There's nothing illegal in the above and the HTML 4.0 spec contains examples;
the semantics implied are that adjacent DTs are synonyms.   However
no-one seems to implement DL as it was supposed to be implemented:

Term    Definition

Long Term
       Definition of Long Term


> 
>    b. UL - <TABLE></TABLE>=optional (table begins) (table ends), or HR's
>          <TR></TR> = <ul></ul>
>          TH = <li> with some special emphasis (maybe a line in lynx.lss)
>          TD = <li> without emphasis

You can nest lists.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]