media characterization and formal types in HTML and CSS2

to follow up on what Jason White said:

> Is there any proposal to add more descriptive media types prior
> to the release of HTML 4 and CSS 2, or will this be a later
> refinement that is scheduled for inclusion in a subsequent
> version of the standards? In the latter case, this working
> group would need to consider whether to take the lead in the
> definition of media types, or whether to wait until the
> HTML/CSS working groups have developed their approach more
> concretely. 

At the very least we should try to analyze how the ability
to refer to user interface media impinges on the interest of
users with disabilities, and articulate what we find as 
clearly as we can.

In the area of solutions, we should neither sit back and wait
nor assume we have the lead.  We should approach our work
as preparing notes for a dialog.  One of the latest buzzwords
in labor/management relations that I have heard is interest-based
problem solving.  That is my ideal model for what we are doing.
We are preparing our inputs for a joint meeting with representatives
of other users of HTML and CSS so that together we can find a
better answer to these problems.

There is a specific suggestion on the table, but not endorsed
by the HC group, to the effect that HTML should wash its hands
of the definition of the type used in giving values to the
MEDIA attribute.  HTML would defer to the Stylesheet language
to define the type for the value of this parameter.  This 
possible approach is discussed in 

Style selection and Media types
http://www.access.digex.net/%7Easgilman/web-access/ACSS/styles_vs_media.html

This is not a complete solution because I haven't really dealt
with what CSS2 should do because I did not realize that the two
documents were scheduled to be frozen at the same time.  The
rough concept consistent with my note is that CSS2 would define a
syntax for type indications with at minimum base type labels, a
modifier capability, and a few reserved or predefined base types
and modifiers (but room for more).

The overall approach I am arguing for is that media are
constantly evolving, so we need a widely-understood but
ever-changing vocabulary of names for media types.  The MIME
types registry as operated by IANA for the IETF is an example of
an infrastructure service which maintains such an open dictionary
of globally recognized nomenclature.  It doesn't have to be
exactly like that.  But I do believe it will be more effective to
standardize a syntax with room for expansion in it than to
standardize a fixed, finite list of names.

All of this bears further investigation, both in terms of what
kinds of changes in the HTML and CSS documents would tear up the
least existing tool code, and in terms of what the connection is
between the formal capabilities and the interests of users with
disabilities.

>              Another media type change which has not so far
> been discussed, is the possibility of adding a parameter to the
> SCREEN and PRINT media types to distinguish style sheets that
> are intended to provide large print or special colour schemes
> that would assist users who have low vision.  Although the
> current SCREEN and PRINT media types would allow large fonts or
> specific colours to be defined in the user's default style
> sheet, there is a risk that such settings are likely to be
> overridden by persistent styles. Authors, I suspect, are likely
> to include font and colour parameters in their persistent
> styles. The definition of a special media type would at least
> neutralise the detrimental impact of such practices, since the
> user's default style sheet can only be overridden by another
> style of the same media type. Another approach would be to
> reconsider the whole issue of whether users should be permitted
> to override persistent styles, in the manner that Al has
> suggested in his response to the ACSS action item.

In terms of the control logic, I didn't go beyond my earlier note
other than to say HTML should not own this algorithm, but use
examples from an algorithm that CSS1 or CSS2 owns to illustrate
how the information originating in the LINK elements is applied.

Even in the current draft, the user is given ultimate control,
but only through a rather blunt instrument: the user can turn all
stylesheet processing off.  I think we can make style selection
more like the interest-based negotiation I referred to above.
Here the initial decision to retrieve a stylesheet is not a final
commitment to use it.

The browser may retrieve one stylesheet based on the information
in the HTML and then discover conflicts between the details of
that stylesheet and preferences of the user.  At that point it
would make more sense to re-run stylesheet selection than to
abandon stylesheet processing entirely.

How much of this adaptation logic can be done in one stylesheet,
vs. when one starts over with a different stylesheet or set of
stylesheets -- that is a function of the stylesheet language.
That is why I recommended that HTML not try to state a definitive
algorithm, but rather defer to the stylesheet language and use
CSS examples for clarity and motivation.

Every browser that has any interest in retrieving a stylesheet
file has to understand the language of that file.  It is not just
an HTML-aware tool, it is also a Stylesheet-language-X-aware
tool.  We don't have to define the stylesheet-processing behavior
in the HTML specification just because HTML files will contain
references to stylesheets.

--
Al

Received on Friday, 19 September 1997 12:41:49 UTC