HTML and ICAD: email@example.com
Date: Sat, 3 Sep 94 18:00:38 EDT
To: Multiple recipients of list <firstname.lastname@example.org>
Subject: HTML and ICAD:
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: HTML Working Group (Private)
I think the sooner the integration between ICAD and HTML happens the better it
is for all concerned.
So I'd advocate Yuri's approach of including most of the ICAD tags that do not
appear in HTML2.0 as "proposed" in the current drafts.
I'd also like to point out that rendering documents in Braille imposes
requirements on the electronic encoding very similar to the requirements for
visual rendering, since both address displaying the information on a
Rendering the information orally, i.e. speaking it makes things a little more
interesting in terms of the requirements of structural markup.
To give an example: both a visual formatter, and a Braille formatter can make
do with a tag such as
"render this in large font" in place of "this is a section title". (although
even in this case I would abhore such usage).
However, when rendering information orally, one has to contend with the
relentless linearity of audio, and compensate for this by allowing the user to
obtain "multiple views" of the information being presented; e.g.
1) Obtain outline views of the document;
2) Interactively jump to different portions of the document structure;
This means that the browser used needs to be able to construct a sufficiently
rich high-level representation of the information structure present in the
document. To enable this, the electronic encoding has to contain full
structural markup, e.g. as encouraged by markup systems like SGML, HTML, and
LaTeX. (of course all of these markup systems can be abused; and some more
than others; which is why SGML purists might dislike mentioning LaTeX in the
For a detailed discussion on the issues raised by rendering information in
P.S. I'd like to subscribe to this list.
Could the list owner please add me to the list?