Re: "@import" positional validity

> 
> 
> Section 4.1.5, "At-rules", in the CSS 2.1 specification 
> (<http://www.w3.org/TR/CSS21/syndata.html#at-rules>):
> 
> "CSS 2.1 user agents must ignore any '@import' rule that occurs inside 
> a block or that doesn't precede all rule sets."

I get the impression that someone has got carried away with the idea of
specifying error recovery behaviour here.  I think they are really trying
to constrain authors, not user agents (and consequently future 
specifications).  Unless one actually envisages @import having a meaning
within any sort of block defined in CSS2.1 or after other rules, in
future versions, it really doesn't matter how the user agent recovers from
the invalid construct.

> 
> Considering the passage literally, what is the validity of the 
> "@import" at-rule in the following style sheet?
> 
> @media all {}
> @import url("http://example.com/style-sheet.css");
> 
> If the "@import" at-rule is valid, it seems that the specification has 
> accidentally left a loophole. If the "@import" at-rule is invalid, on 
> what basis is it invalid?

I presume the policy behind the rule is that one should be able to process
the style sheets forwards only whilst only remembering normal and !important
matches, and still be able to use a cascade rule that applies imported 
sheets with lower precedence than the importing sheet.  From that point of
view, the anomalous position of the @import doesn't cause a problem because
all of the rules in the imported sheet can be processed before all of
those in the importing sheet simply by reading the @import file at the time
the @import is encountered.

> 
> "error" {}
> @import url("http://example.com/style-sheet.css");
> 

This makes more sense if one realises that the rules are not about what
to do when you meet "error", but about what you do when  you meet
"future valid construct".  A back version browser cannot know whether
future valid construct can introduce rulesets, so it must assume that
the CSS is valid CSS and that the future construct doesn't, in fact,
introduce them.  If future construct does introduce rulesets, then the
CSS is unconditionally invalid in the future version browser, and should
not have been written.

The recovery rules are not about achieving consistent error behaviour, but
about achieving consistent tolerance of valid future versions.

Received on Sunday, 10 October 2004 14:07:21 UTC