W3C home > Mailing lists > Public > w3c-wai-hc@w3.org > October to December 1997

Re: Media type recognition by HTML user agents

From: Jason White <jasonw@ariel.ucs.unimelb.EDU.AU>
Date: Sat, 25 Oct 1997 11:34:23 +1000 (AEST)
To: WAI HC Working Group <w3c-wai-hc@w3.org>
Message-ID: <Pine.SUN.3.95.971025111625.14705A-100000@ariel.ucs.unimelb.EDU.AU>
I understood our position to be that media types, including additional
base types and extensions to existing types, should be able to evolve
without requiring changes to the HTML specification. With this objective
in mind, the October 17 draft of HTML 4.0 is still problematic.

Quoting the relevant passage:

          Future versions of HTML may introduce new values and may allow
          parameterized values.
[This development should not be dependent on future versions of HTML. The
entire purpose of our proposal, as I understand it, is to make the
definition of media types independent of the HTML specification.]

 To facilitate the introduction of these
          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:

"print and resolution > 90dpi"
         2. Each entry is truncated just before the first character that
            isn't a US ASCII letter [a-zA-Z] (Unicode decimal 65-90,
            97-122), numeric digit [0-9] (Unicode hex 30-39), or hyphen
[Here is the problem. It is only a minimally conforming user agent which
should truncate each entry in this way, and restrict itself to the
predefined list of media types. It should be possible for user agents to
process and act on the additional parameters without violating the HTML

 In the example, this gives:

         3. A case-sensitive match is then made with the set of media
            types defined above. Entries that don't match should [changed
to "may", pursuent to Dave's amendment] be
            ignored. In the example we are left with screen and print.

When Al and I were discussing this issue a few weeks ago, we raised the
possibility that media types would be defined by the currently active
style language (E.G. CSS). Thus, any media type containing parameters or
an unrecognised base type, would in effect be sent to the style sheet
handler for processing. This approach seems flawed, in that some style
languages may not support the notion of a media type.

Perhaps it would be better for media types to be developed in a separate
specification, as Daniel has been suggesting. In that case, we need to
make it clear that the truncation is not mandatory but only required of a
minimally conforming user agent, and that additional parameters (following
the base type name ans preceding the comma) may be recognised, as well as
new base types. The statement that future versions of HTML may define
extensions to media types also needs to be changed, since it is our
intention that the definition of media types should not be a function of
the HTML specification.

I am sure that we can arrive at a mutually satisfying approach to this
Received on Friday, 24 October 1997 21:34:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:35:00 UTC