- From: Jason White <jasonw@ariel.ucs.unimelb.EDU.AU>
- Date: Fri, 24 Oct 1997 14:58:42 +1000 (AEST)
- To: WAI HC Working Group <w3c-wai-hc@w3.org>
I realise that I am making this suggestion far too late in the WAI HTML review process, but in any case it is not of major importance by comparison with the other problems that have been occupying our attention recently. The PRE element in HTML is somewhat anomalous, in that it is intended to preserve the line breaks and spacing of the enclosed text. Such a rendering can not be supported by braille devices, unless a code for computer notation is used which provides a specific means of representing line endings and space characters. Such a code is intended to represent the text of computer programmes. Similarly, audio user agents are not likely to inform the user of the spacing and line breaks which are presented in a PRE element. Braille translation software needs to determine whether the preformatted material is meant to be treated as programme code or as ordinary text (in a natural language). This requirement can be met by setting aside a CLASS value: <pre class="code"> program pascal_sample; begin writeln ("This is a programme written in the Pascal language"); [...] end. </pre> A braille translator, recognising the reserved class name, would process this text as computer notation. However, in the HTML 4.0 draft, there is an example of a poem which has been formatted using the PRE element. In such cases, the braille software should treat the text as natural language, and would need to ignore the spacing and line breaks. These considerations lead to the following question: should a comment be included in the description of PRE, which explains that non-visual user agents may ignore the spacing and line breaks in this element's content? As I have explained, a braille formatter will not always ignore the spacing of preformatted text, which can be represented, if necessary, using the braille code for computer notation. However, as the poetry example indicates, this is not always appropriate; and of course, audio devices are likely to ignore the spacing in any case.
Received on Friday, 24 October 1997 00:59:30 UTC