Re: Aural Cascading Style Sheets

[Håkon Lie:]

| HTML is device independent and there is no need to integrate aural
| presentation into HTML. In fact, it's a bad idea to put presentational
| information into HTML since authors are likely to only support the
| most popular presentation devices such as 800x600 screens thus
| reducing accesibility for speech synthesizers, printers, computer
| displays of the future etc. Instead of stuffing everything into HTML,
| we should -- as the SGML/ODA communities discovered long time ago --
| separate content from presentation.

As I said before, aural presentation is not an area in which I am
qualified to comment.  However, a group of researchers at Sun has
developed an entire speech synthesis language based on HTML, and in
the process they were forced to add CLASS attribute values to SPAN
such as sentence, phrase, compound, and a number of others in order to
distinguish language features in the text itself.  These were not
presentational descriptions but rather information that needed to be
in the text in order to make linguistic distinctions for downstream
aural presentation processing.  This team was also forced to add
nonstandard attributes to HTML in order to convey the complete set of
information needed properly to drive speech synthesis.

I am not suggesting that you use these or any other features because I
am not qualified to make such suggestions.  I am only pointing out
that what appears to be a similar effort by people who are qualified
for this work was in fact forced to do so.

[Dave Raggett:]

| I think there is a good case for markup to indicate how to speak
| certain words or phrases, when this also serves to amplify the
| semantics.
| For instance, indicate that something is an acronym, abbreviation,
| a person's name etc. It makes sense in some cases to specify the
| long form as an attribute, e.g. one could write
|  <acronym for="Cascading Style Sheets">CSS</acronym>
|  <abbrev for="etcetera">etc.</abbrev>
|  <person fullname="David St.John Raggett">Dave</person>
| [...]

This is consistent with the experience of the team referred to above.

| It would be great to collect suggestions for enlarging the set
| of phrase tags for future versions of HTML. Is there a core
| set that will meet say 95% of people's needs?

If you continue to add more standardized tags every time you encounter
a new problem domain you will destroy HTML as a simple markup
language.  SGML went down this road a long time ago in the attempt to
define universal tag sets and found out the futility of this approach
through exactly the kind of experience that you are about to repeat.
It was discovered then that the answer is not to keep adding more
hardwired tags but to provide a standard way of extending tag sets as
needed to optimize them for particular problem domains.  XML provides
such a standardized extensible language definition mechanism for the
Internet, which is why I suggested that it be looked into for this


 Jon Bosak, Online Information Technology Architect, Sun Microsystems
 2550 Garcia Ave., MPK17-101,           |  Best is he that inuents,
 Mountain View, California 94043        |  the next he that followes
 Davenport Group::SGML Open::ANSI X3V1  |  forth and eekes out a good
 ::ISO/IEC JTC1/SC18/WG8::W3C SGML ERB  |  inuention.

Follow-Ups: References: