Re: LYNX-DEV Internal MIME types

[Klaus Weide]

On Sat, 26 Apr 1997, Al Gilman wrote:

> My metaphoric use of physics and EE concepts taxes your parser.

:)
 
> I was addressing Klaus's one-liner about "what does the Netscape
> parse strategy have to do with accessibility?"

That question was actually referring to what C. Maden suggested for an
in-memory structure of parsed documents, or what I understand of it.
He mentioned that the "WAI folks are very excited about [it]", therefore
my question.  The "it", I assume, refers to Microsoft's DOM.  (Well I am
more familiar with DOOM than with what DOM means. :} )

> The Netscape parse strategy is based on the idea that there are
> different, mostly independent aspects of the material to be
> presented.  How you manipulate one stack is independent of where
> you are in another.

The Netscape parse strategy, OTOH - or what I can guess without having
experimented with it - seems to say that it is perfectly fine to start
a section of underlining in one paragraph and end it in the next, or to
let a FORM begin in the middle of a TABLE cell and end it three pages
down, in the middle of an Ordered List.  This gives NO benefit to the
reader/viewer; for the provider side, it just encourages sloppy authoring,
sloppy authoring tools, and sloppy thinking.  It provides not more, but
much less accessibility, because the only medium where the results
of the different "stacks" fall together to some semblance of meaning and
coherence is the one which the author used.  Or, more likely, the same
browser and display settings which the author used.

[...]

> Let us take a very small example: the counter that tells you that
> you are the 39457th visitor to the page.  Through a quirk of the
> standards, to make this dynamic, you have to make it an image.

Not as much a quirk of the standards.  More, I suspect, that the early
Mosaic programmers found it much more cool to inline pictures than to
inline text, and the rest is history.

Anyway, there's nothing technical prohibiting text counters (but they need
server-side includes or similar).  People are not using them (much).  That
would require talking to their Webmasters or service providers, well it's
just so much easier to link to this FREE graphics thingie.

There is also nothing preventing provision of pages in multiple formats,
for multiple kinds of devices, on the contrary mechanisms for it have been
within the HTTP protocol from (near?) the beginning.  For years these
mechanisms (content negotiation) have remained unused, undeveloped, and
become even *less* used.  Or about those SDA things that were once part of
HTML.  Quote from RFC1866: "to support usable access to
  structured information by print-impaired individuals through
  Braille, large print and voice synthesis".
Well they dropped out of later versions of the spec, seem to have
disappeared.

The mass market driving forces of this "spread the Web" phenomenon seem to
have been, so far, unfavorable to really developing its potential.  It's
about making it accessible to a great number of people, not about 
inventing mechanisms or making accomodations for anybody deviating to much
from the targeted norm.  If that happens, it seems more by accident than
by an effort.  (And those companies which *do* target the non-average
customers make them pay a lot for it, I understand.)

So it appears to me that these are social problems, not results of 
technical barriers.  A new data format or a new document structure won't
change much.  IMHO, of course.

   Klaus

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;