- From: Wendy A Chisholm <chisholm@trace.wisc.edu>
- Date: Thu, 10 Sep 1998 09:38:42 -0500
- To: "John T. Whelan" <whelan@physics.utah.edu>
- Cc: w3c-wai-gl@w3.org
> 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 ><wink>. > 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