Re: Some comments on the recent HTML discussion

The current spec for HTML 4.0 does go to some lengths to future
proof media descriptors. It would allow us to refine the braille
type with modifiers such as "braille online" or "braille 40x60".
User agents conforming to the current 4.0 spec would see both of
these as simply "braille". Here an excerpt from the 4.0 spec:

       In the future, there may be more values, and each value may
       have associated with parameters. To enable the smooth
       introduction of such extensions, user agents conforming to
       this specification must be able to parse the media attribute
       value as follows:

           1. Comma characters (Unicode decimal 44) are used to
              break the media attribute value into a list of entries,
              e.g.

              media="screen, 3d-glasses, print and resolution > 90dpi"

              is mapped to: 

                "screen"
                "3d-glasses"
                "print and resolution > 90dpi"

           2. Each entry is truncated just before the first
              character which isn't a US ASCII letter [a-zA-Z]
              (Unicode decimal 65-90, 97-122), or hyphen (45) .
              In the example, this gives: 

                "screen"
                "3d-glasses"
                "print"

           3. A case-sensitive match is then made with the set of
              media types defined above. Entries that don't match
              should be ignored. In the example we are left with
              screen and print. 


> 
> 2. I would like clarification of the proposal to reserve link
> types for accessibility-related resources. If the plan is to
> establish a key word which, if present, declares that the linked
> resource is intended for purposes of accessibility (for example an
> audio version of a document; perhaps in talking book format) then
> I think the approach is meritorious. However, certain types of
> resource that we have been discussing are not exclusively related
> to accessibility. For example, an abbreviation dictionary is
> important to speech output, but it may also be used by a spelling
> checker, or as a mechanism by which a link can be associated with
> each abbreviation, which, if activated, displays its expansion
> (this might be desirable in some educational settings, though the
> spelling checker illustration is a more commonplace application).
> Thus, care should be taken in deciding which link types should be
> associated with an "accessibility" key-word. As Daniel has
> suggested, CLASS may be a better location for the declaration of
> the type of dictionary (rel="dictionary"  class="abbreviation"). 

What are the benefits obtained by separating "dictionary" out as a
distinct term, as compared with say:

   <LINK rel=abbrev-dict href=abbrev.xml>

> 
> 3. If we decide to accept the LONGDESC proposal, then I would
> suggest that LONGDESC be added to FRAME as well as to IMG. The
> rationale is obvious: currently it is possible to load an image
> directly into a frame by way of the SRC attribute in the frame's
> definition. TITLE and LONGDESC would together allow a textual
> alternative to be specified by the author. 

This seems a reasonable addition.

> 4. To enable style sheets to control the reading order of an HTML
> document (if, indeed, we decide upon this as the best strategy),
> it may be desirable to define standard classes for certain
> frequently occurring constructs, such as navigation bars, which it
> would often be necessary to move in order to give an efficient
> braille or audio rendering. 

Another reasonable idea. An alternative is to get authors to
specify aural reading order directly in some manner. An indirection
via class names would be useful though, e.g. you could then
in principle specify reading order in a style sheet.

Regards,

-- Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
phone: +44 122 578 2521 (office) +44 385 320 444 (gsm mobile)
World Wide Web Consortium (on assignment from HP Labs)

Received on Monday, 22 September 1997 05:40:52 UTC