Re: Comments on WAI guidelines

>	Whoops, I was quoting the wrong example.  I was thinking of
>the subsequent paragraph
>
>" Another way to replace ascii art is to use human language
>" substitutes. For example, <wink> might substitute for the emoticon
>" <SPAN alt="wink" title="wink smiley">;-)</SPAN>,
>
>which uses ALT as well as TITLE on a SPAN (although I suppose it's not
>actually an example).
>
>	Oh, and of course <wink> would have to be written as
>&lt;wink&gt;.
>
good eye, thanks.  these have been corrected.

>>><OBJECT DATA="cow.txt" TYPE="text/x-ascii-art" TITLE="drawing of a cow">
>>>Cow
>>></OBJECT>
>
>>yes, this is another interesting way to do this.
>
>	Although only useful if agreement is reached on the MIME type
>and browser makers are aware of it.
>					
According to RFC1521 [1] ("MIME (Multipurpose Internet Mail Extensions)
Part One: Mechanisms for Specifying and Describing the Format of Internet
Message Bodies") there are already several subtypes of the MIME type
"text."  One of these is "plain" which refers to unformatted text.
"Richtext" is another subtype, but from the definition given in RFC1341
[2], richtext refers to SGML like text with a DTD.  

So, ASCII art is "plain" text in that it does not contain markup.  The
spaces and tabs are just ASCII characters.  Can a UA assume that if an
OBJECT contains plain text that it is ASCII art?

At any rate, here is what RFC1521 says about the text content-type:

7.1 The Text Content-Type

The text Content-Type is intended for sending material which is principally
textual in form. It is the default Content-Type. A "charset" parameter may
be used to
indicate the character set of the body text for some text subtypes, notably
including the primary subtype, "text/plain", which indicates plain
(unformatted) text. The
default Content-Type for Internet mail is "text/plain; charset=us- ascii". 

Beyond plain text, there are many formats for representing what might be
known as "extended text" -- text with embedded formatting and presentation
information.
An interesting characteristic of many such representations is that they are
to some extent readable even without the software that interprets them. It
is useful, then,
to distinguish them, at the highest level, from such unreadable data as
images, audio, or text represented in an unreadable form. In the absence of
appropriate
interpretation software, it is reasonable to show subtypes of text to the
user, while it is not reasonable to do so with most nontextual data. 

Such formatted textual data should be represented using subtypes of text.
Plausible subtypes of text are typically given by the common name of the
representation
format, e.g., "text/richtext" [RFC-1341]. 

[1] RFC1521 http://www.marlant.hlfx.dnd.ca/Connected/RFC/1521/12.html 
[2] RFC1341 http://www.kisco.co.kr/RFC/rfc/rfc1341.html

Received on Thursday, 10 September 1998 10:43:24 UTC