- From: Chris Lilley <Chris.Lilley@sophia.inria.fr>
- Date: Fri, 10 Jan 1997 18:33:31 +0100 (MET)
- To: Aymeric Poulain Maubant <Aymeric.PoulainMaubant@enst-bretagne.fr>, www-style@www10.w3.org
- Message-Id: <9701101833.ZM14746@grommit.inria.fr>
On Jan 10, 3:45pm, Aymeric Poulain Maubant wrote: > Håkon wrote: > > HTML is device independent and there is no need to integrate aural > > presentation into HTML. [...] > I really do know what is HTML, SGML and CSS1 :-) ... I know you do. (For people on the list who haven't mey Aymeric before, he translated a tutorial on HTML, CSS and HTTP which I wrote in 1995 into French. ( See http://webbo.enst-bretagne.fr/ActiveWebFr/index.fr.html ) > take <img src="..." alt="..."> ; ALT was created for users who *do > not have* bitmap-oriented browsers (namely lynx). Yes, and I agree that it can be seen as a presentational hint for text-only browsers. It can alternatively be seen as adding semantic markup to an inline image. So for example an image of some nice typography that gives the main heading of a page could have alt text describing what the (pictures of words) actually say. > When reading ACCS, I found 1/ that Chris seems to suggest that some > stuff addressed in ACCS (like speak-date) should not be in fact in > the CSS, Right, I said it should be in HTML. By that I meant that it was semantic information, independent of presentation. It might also be used by indexing or search engines for example. I recall that mark-up for dates and times was in an early draft of the Internationalisation internet draft, but that also included markup for currency and valid concerns about the timeliness of automatic curency conversion resulted in the baby being thrown out with the bathwater ;-) > and 2/ that speak-punctuation does not address the problem > of punctuation having a semantic meaning ("[ choice1 | choice2 ]" for > instance). This particular example can be addressed in CCS1 by making LI inline instead of list items. But in general I agree that HTML is not especially good at capturing semantics, and also that this lack is more noticeable when using speech rendering. For example, grouping by 2D positioning conveys relationship well to the sighted reader, but does not help someone who is listening to a 1D spoken rendition: 1A 1B -- 1C 1D 1E 2A 2B -- 2C 2D 2E You can clearly see that 1D and 2D are somehow related, but you cannot clearly hear it. Another example - you can clearly see this $25,370 as twenty five thousand, three hundred and seventy dollars. And this FF25,370 as 25 French francs and 27 centimes ;-) since many European countries use comma as a decimal separator and period as a thousands separator. There are many other examples. The upshot is that, in addition to describing aural presentation (in the stylesheet) it may be necessary to add semantic mark-up (in the HTML) whose lack was upt to now not apparent to most of us. > Thus I thought that an attribute for span might be > useful : > <span altread="Here is a menu">[ choice1 | choice2]</span> I would suggest instead this sort of construct <p class=menu><a class=menuitem href=foo>choice 1</a> <span id=001>|</span> <a class=menuitem href=bar>choice 2</a></p> with this stylesheet fragment .menu { cue-before: url(menualert.au) } .menuitem { cue-before: url(choice.au) } #001 { display: none } > If we do not want to put such a functionnality into HTML (which is > sensible as well), I do not see how to put it in the speack punctuation > property. The following could be an idea : > > speak-punctuation > value: code | altread | none > initial: none > Applies to: all elements but altread which applies only for span > inherited: yes /* but what does mean inherited for altread which applies > only for SPAN ? */ Yes, you see the problem. In general, experience with alternative forms (be they alt, noframes, or whatever) is that they are too hard to keep in sync with changes to (what the authors see as) the 'main' version. People simply don't use them. I have seen some examples of Web pages that appear to have an aural stylesheet -- they were linked from Apple's macintalk page, http://speech.apple.com/ -- but these actually used a plug-in which downloaded a text version of the page )or, part of the page) with embedded control codes for a particular speech synthesizer. Not very portable, not very maintainable. I feel that ACSS provides a superior approach where the actual HTML is used as the basis for rendering the speech and the browser generates the requisite control codes for whatever system the reader is using, based on the stylesheet. It is better to design mark-up which can automatically be presented in different ways. The advantage of stylesheets in general, and of CSS in particular, is that presentation can be defined which the original document author did not think of. If the author did not design with any aural capabilities in mind, the readers default stylesheet can still be used to generate a reasonable rendition. > UA are encouraged to guess the special meaning (this > is out of the scope of ACSS specification) : "|" could be spoken "or", for > instance, "[foobar]" could be spoken "foobar is a bibliographic entry". In general, we have found that sentences like this give no end of trouble to developers who would prefer the spec to tell them exactly what to do. The speak-date property should ideally be rarely used, and ideally should be used in the dfault stylesheet like this: date { speak-date: dmy } or whatever. That would require an explicit date element in HTML. In the meantime of course, .date { speak-date: dmy } will have to do. > Am I the only one to think there is something missing in the property > speak-punctuation ? No. The original impetus was for stylesheets that speak actual code fragments, like C or Java code examples, that sort of thing. The problem comes when punctuation is used to give semantics, like this - a list item - another one At least HTML solves that one, which is still very common in plain text. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)4 93 65 79 87 06902 Sophia Antipolis Cedex, France
Received on Friday, 10 January 1997 12:33:43 UTC