[whatwg] Re: media types
css at markschenk.com
Mon Jul 26 05:46:58 PDT 2004
On Mon, 26 Jul 2004 12:43:08 +0100, Malcolm Rowe
<malcolm-what at farside.org.uk> wrote:
>> Therefor I would like to suggest a read-only "window.medium" set to a
>> media type ("screen" | "print" | "projection" | "tv" | "handheld" |
>> "speech" etc).
> Not a bad idea, I suppose, but I'd like to understand more about the use
> case for this kind of functionality. What *behaviour* (not presentation,
> since that would be CSS) do you expect you'd change based on the active
> media type?
Basically I want to be able to have some scripts associated with certain
media types. For instance, I would like some scripts to *only* work in
projection, or *only* in handheld.
> [Hmm, you could probably emulate this now: by using CSS's @media blocks,
> and then detecting what style rules were active from script.]
Of course, but that's a dirty hack :)
> Secondly, is 'the current media type' only ever a single value, or can
> more than one media type be active at one time (e.g., 'projection'
> + 'screen'?).
That's a very good question actually, with a lot of debate surrounding
it... let me quote the current CSS2.1 specs:
"Media types are mutually exclusive in the sense that a user agent can
only support one media type when rendering a document. However, user
agents may have different modes which support different media types."
<url: http://www.w3.org/TR/CSS21/media.html >
So basically there would probably be only media type active at the same
time. However, there is a big problem when using a multimodal browser 
which allows different modes visual/aural(/tactile) at the same time.
Different mediatypes would be mutually exclusive within a mode, e.g. you
can't have screen and projection at the same time (they're in the same
mode), but you can have projection and speech, or handheld and speech at
the same time (they're in different modes). This isn't covered by the
CSS2.1 specs (yet), but should definitely not be discussed here, but on
the appropriate W3C list.
However, it doesn't matter much for our case how it is defined by the spec
exactly. The proposed window.medium would return an array instead of a
string. In a multimodal browser, it would then return screen,speech or
print,speech (when in print preview) or handheld,speech (when using
> Finally, 'window.medium' is a really bad choice for the name. I know
> that 'medium' is the right word (if only one can be active), but
> no-one's going to associate 'medium' with 'active media type'.
> 'mediaType' would be better.
Yeah, I could live with that argumentation.
More information about the whatwg