making better ad hoc use of class attribute values

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