W3C home > Mailing lists > Public > www-style@w3.org > June 2008

Re: [css3-mediaqueries] Width/Height Clarifications

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Mon, 09 Jun 2008 12:40:05 -0700
Message-ID: <484D8715.6000509@terrainformatica.com>
To: Andrew Fedoniouk <news@terrainformatica.com>, Anne van Kesteren <annevk@opera.com>, www-style@w3.org

L. David Baron wrote:
> On Monday 2008-06-09 11:08 -0700, Andrew Fedoniouk wrote:
>   
>> <quote src="http://www.w3.org/TR/CSS21/cascade.html#at-import">
>>   So that user agents *can* avoid retrieving resources for unsupported  
>> media types, authors may
>>   specify media-dependent @import rules. These *conditional imports*  
>> specify comma-separated
>>   media types after the URI."
>> </quote>
>>
>> That clearly tells me that I can avoid retrieving resources as a whole  
>> if at parse time I've discovered
>> that media type does not match.
>>     
>
> There's a difference between "media type that you might switch to
> later" and "unsupported media type".
>   
What is the difference? 

These two statements:
@import url(a.css) print;  and
@import url(b.css) screen; 

Are they "unsupported media types" or "media type that you might switch 
to later" ?
According to your previous message you treat them as "media type that 
you might switch to later"
as you are parsing them both. I think it makes sense to specify this 
difference then.
(See my sample at the bottom of the message)

If you parse them both then each rule shall also contain reference to 
media type
(or condition expression in case of MQ) and so be evaluated as if 
following pseudo-class is
defined:

p:media(print)
p:media(screen)
p:media(min-device-width:800 and max-device-width:1024)

etc.

(
   Statements above produced for the following sequence:
  @media print { p{...} }
  @media screen { p{...} }
  @media min-device-width:800 and max-device-width:1024 { p{...} }
)

Am I right in my understanding of how this is going to work?

>   
>> I do not know how you have implemented @media parsing currently but  
>> these two sets:
>> @media screen { p{...} }
>> @media print { p{...} }
>> will create rules with the same value of specificity (they will be  
>> different only by
>> order of selectors in the source).
>>     
>
> Sure. 
>
>   
>> If to speak about MQs that are parsed into runtime sets then I would  
>> like to know also
>> exact specificity rules for selectors inside these two sections:
>>     
>
> There's no influence on specificity rules.  Why did you think there
> was?
>   

> Dynamic changes to media query results have been implemented by
> multiple implementations (WebKit and Opera both pass Acid3, which
> requires getting dynamic changes correct, and I have a patch to
> Mozilla that does the same), so I'm a little puzzled by claims that
> it's impossible.
>   
Consider following css resource:
--- a.css ---
    @media screen
    {
        a { color:green; }
    }   
--- end of a.css ---

And following markup:

<html>
   <style>
    @import url(a.css) print;
  </style>
  <body> <a href="#">test</a> </body>
</html>

that is loaded in UA on media screen.

What color that <a> should have?
If you say that you load and parse everything disregarding of media type
then <a> should have  a { color:green; } applied.
Neither Mozilla nor Opera do that as far as I can tell.

--
Andrew Fedoniouk.

http://terrainfromatica.com
Received on Monday, 9 June 2008 19:40:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:07 GMT