- From: Robert Burns <rob@robburns.com>
- Date: Fri, 31 Aug 2007 12:39:13 -0500
- To: public-html@w3.org
HI Sander, On Aug 31, 2007, at 10:59 AM, Sander Tekelenburg wrote: > > At 12:39 +0100 UTC, on 2007-08-31, Philip Taylor (Webmaster) wrote: > > [...] > >>> ATs could read <i> in a slightly different voice. Or just read it >>> normally >>> and let the surrounding context make clear it's a special term, >>> similar >>> to what a sighted user of a monochrome display would experience. >> >> Yes, they could. But the universe of renderings available to >> screen renderers is considerably richer than that available >> to aural renderers, so whilst I might (say) have an introductory >> gloss that says "All ship names appear in blue italics, foreign >> words and phrases in grey italics, Linnaean binomials in red >> italics and book titles in black italics", I would be hard pressed >> to have a similar introduction to the aural version > > Maybe (I haven't researched speech possibilities enough to judge). > But this > seems to bypass what a user can actually digest. The visual > presentation you > suggest here is similar to syntax colouring. And most of us here > probably > agree that it takes some getting used to a particular syntax colouring > scheme, and then still it's only an aid; we still also rely on > knowledge of > the programming language, we look at the context, etc. So I think > the visual > presentation in your example would only be useful to *very* few > people. > Probably only the few specialists on the subject at hand, and then > still > assuming they are accustomed to that particular visual presentation. > > For a wider audience, such presentation can help, but shouldn't be > the only > indicator. The (con)text will need to be provide good hints. And > once that's > the case, I wonder if the possible variations of aural presentation > would > really be too limited. > > [...] > >> To summarise : the differentiation between a book title, a loan word, >> the name of a ship and a Linnaean binomial /may/ be important in >> some documents, and for those documents, there needs to be a means >> to express the distinction in HTML. > > In principle I agree, but in practice I wonder where to draw the line. > > I'm inclined to think that @class is 'good enough' for this. UAs > can make the > class value available to users (that they don't is just a UA bug > IMO). And > authors can provide a legend to their sites, that explain class names. > Authors can suggest a presentation, and users can choose to > override that > with user CSS. The latter seems reasonable to me at least in cases > where a > site is visited regularly by a user, and the site's author has > bothered to > use descriptive class names and to provide a legend explaining them. I really like this suggestion. It would be great if browsers exposed the class attribute values to users through some mechanisms. Contextual menus, tooltips and elswherein the chrome might all be ways to accomplish this. It would also be nice for browsers to allow using the find feature to find text in class, title, alt, and id attributes (as well as within other alternate equivalent content). As the string is found in each of these places the focus could move to the element and a perhaps brief view displaying the attribute value could appear superimposed over the element. I also think a separate specification should provide a way to specify in plain language the mapping between semantics and the current presentation. In this way, authors would use explicit markup to describe in human language how a class value was being used. Similarly authors would describe in human language in the style sheet how a selector was being used. Then a UA could piece together the language in the style sheet with the language in the HTML to provide a discovery mechanism for the currently presented semantics. Take an example from the current HTML5 draft: "Big Issue: Known issues are usually marked like this. There are some spec-wide issues that have not yet been addressed: case-sensitivity is a very poorly handled topic right now, and the firing of events needs to be unified (right now some bubble, some don't, they all use different text to fire events, etc)." This could be done through some markup or other syntax. Placing the burden for this on CSS, it could be accomplished something like @selectorHeading { .bigissue: "'Known issues" } @selectorDescription { .bigissue: ''There are some spec-wide issues that have not yet been addressed: case-sensitivity is a very poorly handled topic right now, and the firing of events needs to be unified (right now some bubble, some don't, they all use different text to fire events, etc)." } .big-issue { voice-family: 'female'; description:"spoken in a female voice; } .big-issue { color: #E50000; background: white; border: solid red; padding: 0.5em; margin: 1em 0; description:"surrounded by a solid red border";} Which could automatically generate the content (depending on the UA and the users settings): "Known issues are surrounded by a solid red border" or "Known issues are spoken in a female voice" Followed by: "There are some spec-wide issues that have not yet been addressed: case-sensitivity is a very poorly handled topic right now, and the firing of events needs to be unified (right now some bubble, some don't, they all use different text to fire events, etc)." > Obviously the assumption here is [1] that UAs make it easy for > users to write > user CSS (a good UA provides a uuser-friendly UI for that, so that > users do > not have to learn CSS), and [2] that UAs allow users to define user > CSS to > apply to a specific site/domain/section/page. Another thing that > UAs could do > to make users' life easier is to allow the selection of analternate > StyleSheet to be persistent across a site. (Well, AFAIK they don't > yet offer > that. Maybe some do?) That would make authoring of alternate Style > Sheets > much more worth an author's time. These are excellent suggestions too. Take care, Rob
Received on Friday, 31 August 2007 17:43:29 UTC