- From: L. David Baron <dbaron@dbaron.org>
- Date: Mon, 9 Jun 2008 11:39:55 -0700
- To: Andrew Fedoniouk <news@terrainformatica.com>
- Cc: Anne van Kesteren <annevk@opera.com>, www-style@w3.org
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".
> 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.
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Received on Monday, 9 June 2008 18:40:49 UTC