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

Re: media characterization and formal types in HTML and CSS2

From: Al Gilman <asgilman@access.digex.net>
Date: Fri, 19 Sep 1997 22:45:44 -0400 (EDT)
Message-Id: <199709200245.WAA11172@access1.digex.net>
To: w3c-wai-hc@w3.org (HC team)
to follow up on what Jason White said:
[out of order]

>  I would appreciate clarification from Al as to whether these
> comments are on point or whether I have misunderstood his
> approach completely.

Generally on point.  So much so that I want to build on a few points
you raise.

> In the [July] Cougar draft proposal on style sheets, it is
> stated that to allow for more descriptive media type
> characterisations, the value of the media type extends until it
> is delimited by a comma.

Yes, that syntax allows for base type plus (other stuff not
comprehended).  This leaves room for the qualifiers such as what
I talked about so long as any commas in the stylesheet language
syntax for the type indication are escaped in the HTML.  It
doesn't allow for selecting a stylesheet based on whether you
have a 640X480 projection panel or a larger one.

I would still suggest that HTML per se let go of the definition
of the list of base types.  If that list has to change later, it
is then not necessary to change the HTML specification, which
never needed to know in the first place.

>  The main drawback of this solution is that it does not
> accommodate style languages which make no provision for media
> types. Since HTML is supposed to be independent of all style
> languages, this limitation could lead to problems in practice.

It does accomodate such stylesheet languages.  It just does not
support checking the compatibility between a stylesheet and the
local environment without fetching the stylesheet.  In this case
the stylesheets would be retrieved in the order of author
preference and the first one that could be satisfied by the local
environment resources would be used.  The stylesheet processing
could determine if the stylesheet called for unavailable
resources such as sound, color, or visual display.

This case is logically covered, but unlikely to happen.  Given
the author's willingness to deal with stylesheets at all, and
multiple stylesheets in particular, is driven by the need to look
good on a variety of user equipment, it is unlikely that a
media-unaware stylesheet language would be defined or gain much

> With respect to CSS, it is clear that the addition of a new
> media type would require corresponding changes to be made in
> the style language to support the style properties which are
> relevant to that medium. This makes it difficult to envisage
> how an open data base of media types would operate
> independently of the evolution of CSS itself. Each media type
> also requires support within conforming applications so that
> user agents can decide whether the media type matches the
> apabilities of the current output device.

The addition of new media types may require changes to the
styling language, or the language may support user-defined types
described by expressions built on concepts already in the
language.  In the latter case the new medium may require the
writing of type definitions in a stylesheet, or may require the
browser retrieving the type definition from a registry, but not
necessarily require new language elements per se.  My ignorance
of the XML styling proposals is hurting my ability to give a
closely related example.

Even if changes in the media details require some changes in the
styling language, it is good to have it stop there and not ripple
into changes to HTML.

New media do require new Aps and users without new Aps will use
the less demanding styles.  But the whole point of interposing
a styling layer is to insulate the HTML itself from this change.

-- Al
Received on Friday, 19 September 1997 22:45:48 UTC

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