lynx-dev
[Top][All Lists]
Advanced

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

Re: LYNX-DEV addressing mail to your friends


From: Foteos Macrides
Subject: Re: LYNX-DEV addressing mail to your friends
Date: Thu, 25 Sep 1997 17:49:49 -0500 (EST)

David Woolley <address@hidden> wrote:
>> them.  However, the TAB element is not a container (has no end tag).
>
>It *was* the end tag I was commenting on, although my initial attempt
>to exceed my brief and provide good Lynx formatting on dynamically
>generated tables suggests that tab only works as an alternative if you
>know the number of columns and their maximum widths at coding time,
>and lines in table cells never need wrapping.

        TAB can be used to create tables, but that is not its intention.
Its portable uses (i.e., such that the content is still communicated
for browsers which do not support it) are limited, but exist.

        The issue of line wrapping w.r.t. to TABLEs is irrelevant
as far as Lynx is concerned, because it can't do horizontal scrolling
(and don't confuse scrolling of text/plain presentations with scrolling
in relation to HTML markup).  The most useful aspect of TAB is ability
to set arbitrary tab stops for lining up text, wherever it might occur
in the browser's window, i.e, regardless of window widths and fonts.
For example:

        <em>term</em>: <TAB ID=def1>first definition blah blah<BR>
        <TAB TO=def1>more blah blah blah.<BR>
        
will yield:

        term: first definition blah blah
              more blah blah blah.

but in Lynx, if the blah blahs extend past the right margin for the
style, you'll still get wrapping which messes up what's intended,
just as you would with Lynx for TDs in TABLEs.  Browsers which do
not support TAB will show:

        term: first definition blah blah
        more blah blay blah.

with "term" emphasized, so the "term followed by definition" structure
should still get across to the user.


>>      I'm not sure in what sense you are using "non-proprietary".
>> The HTML 3.0 draft and the HTML i18n RFC are the last HTML specs based
>
>I misdiagnosed plain as being a Netscape or Microsoft extension as it
>wasn't in HTML 4.0 and 3.2.  I don't find 3.0 a useful reference given
>that most pages are written to the empirical behaviour of Netscape and
>Microsoft, which largely ignore this version of HTML.
>
>> on fully public, archived discussions and consensus in chartered IETF
>> working groups (in those cases, the HTML-WG).
>
>If you believe there is still hope for evolution of HTML which is not
>controlled by Netscape and Microsoft, I think you should be campaigning
>against all attempts to make Lynx tolerate pages written for their
>products, otherwise you are admitting that what happens on the real
>web bares little relation to the standards set by IETF committees
>(I think this is a bad thing, but was inevitable when the internet
>lost its protection from the commercial world.)

        I apparently miscommunicated my point.  The HTML 3.0 draft
and HTML i18n RFC (and an ISO HTML spec which few people know about
and to which even fewer people pay any attention :) are the last specs
that legitemately could be described as non-proprietary -- AND -- the
IETF HTML-WG was closed out with no realistic prospects of the IETF
chartering another HTML working group.  The W3C HTML "specs" are not
"standards" based on open, Internet wide consensus.  They are a paying
vendor organization's "recommendations" as stressed in:

   Linkname: W3C Recommendation Process
        URL: http://www.w3.org/Consortium/Process/Recommendation

carring the caveat:
                          W3C Recommendation Process
                                       
   This describes the process by which specifications may be given the
                                       ^^^^
   status of "W3C Recommendations" indicating that the a general
                  ^^^^^^^^^^^^^^^
   consensus has been reached among members that the specification is
                              ^^^^^^^^^^^^^
   appropriate for use.
   
   This process is an alternative to, and not a replacement for or
   modification of the standards process in the W3C member agreement. The
   result of the W3C recommendation process may be submitted to a formal
                                            ^^^                   ^^^^^^
   standards body for ratification.
   ^^^^^^^^^^^^^^

        Declaring a spec as a "standard" carries legal culpabilities,
which, on the Internet and for HTML, only the IETF (and only in the
past for HTML) and ISO (still for HTML, but who cares :) by virtue
of their fully open consensus-based procedures, have been willing to
accept.

        More importantly, whether you find HTML 3.0 "useful" or not,
that is the HTML upon which current versions of Lynx, as well as the
current fotemods and devel code, are based, supplemented by Netscapisms,
MSIEisms, and a piddling amount of HTML 4.0 stuff that I've added.
Also, whether you as yet realize it, HTML 3.0 was written primarily
by Dave Raggett and other members of the W3C in-house staff, and the
seeming abandonment of what's in it upon the W3C's killing of the
IETF's HTML-WG and release of the highly stripped down W3C HTML 3.2
is only "seeming".  Their hope was too move the richer HTML 3.0 capabilies
to style sheets.  That is why, at the time of the Lynx v2.6 release
(Sept. 2, 1996), implementing style sheet support and then incorporating
the chartrans mods "seemed" like they should be the highest priorities.
Lynx already had ways of doing things intended by style sheet interfaces,
so linkages to those, rather than just to the elements and attributes
of HTML 3.0 markup could be added, albeit that the initial impetus for
Lynx styles mods was just "colorizing".  Moreover, with the chartrans
enhancements or their equivalents incorporated, linkages to the i18n
interfaces would no longer be as hopelessly out of reach for Lynx.
There was plenty of lead time, and whether you heed my warnings or
not, it *is* running out.

        What wasn't clear then, but is now, is that without a scripting
interface (based on the DOM effort, albeit closed until possible NS
and/or MS vetos are assessed, and not specifically their JavaScript
and/or JScript) a growing amount of worthwhile stuff (not just glitz
and blitz) on the Web will be out of reach for Lynx, even though
important aspects of it could be (as Scott indicated for his site).

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

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