- From: Mark Schenk <css@markschenk.com>
- Date: Mon, 26 Jul 2004 14:46:58 +0200
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 [1] 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 multimodal handheld). > 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. [1] http://www.opera.com/pressreleases/en/2004/07/26/ -- Mark Schenk
Received on Monday, 26 July 2004 05:46:58 UTC