[whatwg] Re: media types

[Jonny Axelsson]

On Mon, 26 Jul 2004 14:45:21 +0100, Malcolm Rowe  
<malcolm-what at farside.org.uk> wrote:

> Should the UA fire an event when changing the media type? (Opera's  
> full-screen mode, for example).

Opera reevalutes the current document style sheets if the media change for  
a given window. We probably would have to do the same for behaviours if we  
were to support this. If the author has made good device-independent pages  
you wouldn't really need to switch media types often. The exceptions would  
be printing and presentations (you would likely want to see the page as a  
presentation and then go back to what you had before).


> Hmm. Would this make it easy for authors to prevent pages from being  
> printed? I wouldn't want that.

Neither would I. You could do this today with your dirty hack below. The  
obvious workaround would be to turn off JavaScript. That could be  
countered by making the entire page document.write (or equivalent), which  
wouldn't be a problem until we reevaluated the behaviours.

If this turns out to be a non-hypothetical problem, we would have an  
arsenal of methods to counteract this, including printing pages using the  
screen medium.


>>> [dirty hack]
>> Yes you can, but that must be considered a rather ugly hack.
> I know. I never suggested it was a good idea, but I'm rather pleased  
> with the 'eurgh' response it seems to have elicited from everyone. :-)

It might please you even more that it is actually in use by people making  
OperaShow (@media projection) presentations.


>> No, a given canvas can only have one media type. Projection and screen   
>> (and print and ...) are mutually exclusive. But you can have different   
>> media type for each window.
>
> Ok - and on a 'multi-modal' browser, you effectively have more than one  
> 'window'? (though only one 'current position', the same in each window,  
> I guess).

This depends on the implementation or context. In an XHTML+Voice document,  
where you speak content dependent on events, the actual spoken content can  
be far away from whereever the current focus is.

I have aired the idea of a ":spoken" pseudo-class so that you could style  
specially the element currently being spoken. There haven't been that many  
use cases for this yet, but it is a potentially useful feature. Conversely  
a 'navover' (in lack of a better name) event could be an abstract event to  
encompass 'mouseover' (and :hover), only for keyboard and voice.  
'mouseover' doesn't mix well other input mechanisms, including  
stylus/touchscreen.


> You said above that each window can have a different media type, so it  
> doesn't make sense to talk about the 'media type' of a document - it's  
> purely a presentational thing.

Or more precisely a viewport state thing.


> In principle, I wouldn't strenuouslyobject to reflecting a window  
> property into the document property,

My point was that "media type" has two very different meanings depending  
on whether it is CSS or HTTP/MIME. There is ample room for confusion here,  
so I would avoid "mediaType" as a property name.


> No, the thing that I was objecting to more was that the noun 'medium',  
> without any context, is far from obvious as a description. I'm not sure  
> that 'mediaType' is that likely to be confused with Content-Type, but if  
> it is, use something else. I just think that someone reading  
> 'window.medium' is likely to think: "what about window.small or  
> window.large?". I know I would.

There is a context, namely the window object it belongs to. In other words  
the window medium. But if we were to be less gramatically pedantic,  
window.media would be one alternative.

-- 
Jonny Axelsson,
Web standards,
Opera Software ASA