W3C home > Mailing lists > Public > www-style@w3.org > February 2009

RE: [css21] @import parsing

From: Justin Rogers <justrog@microsoft.com>
Date: Wed, 11 Feb 2009 12:21:53 -0800
To: Faruk Ateš <faruk@apple.com>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <00BD06E707F60B4F9D6A3E75C712209D67BB32E236@NA-EXMSG-C104.redmond.corp.microsoft.com>
Hum, since we are now tasked with the decision about what to do with the Microsoft test case which was originally considered, I figured I would weigh in quickly.

1am { color: red; }

I would consider the above not syntactically correct with even the core grammar (well at least the relaxed grammar in CSS 2.1 Appendix G), and thus I would throw it out. It isn't that this is unknown to me like @foo {}, but instead it cannot be considered an at-rule and it cannot be considered to be a rule-set. I think it is fully correct for us to throw it out entirely and allow an @import to follow. Further I have no corresponding CSS OM structure with which I can represent the above since anyone asking for the selector portion of a rule-set is going to expect that the selector is actually valid which would mean that we need an identifier which 1am is not.

Second, I would like everyone to consider that the term invalid is extremely loaded. There is syntactically invalid (doesn't follow the grammar or prose) and functionally invalid (follows grammar rules, but is unknown to the browser and therefore nothing can be done with it). In the end, browser implementations generally look to follow the functionally invalid approach for @import parsing. For example, an unknown at-rule will allow @import to follow it, even if it is syntactically correct.

Justin Rogers [MSFT]

From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Faruk Ates
Sent: Tuesday, February 10, 2009 1:03 PM
To: www-style@w3.org
Subject: Re: [css21] @import parsing

On Feb 4, 2009, at 1:55 PM, L. David Baron wrote:


On Wednesday 2009-02-04 13:43 -0800, Peter Linss wrote:

Agreed. Perhaps the text should read: "after any well-formed statement",
or simply "after any statement".

I'm a little uncomfortable with ignoring @import after an unknown
@-rule.  That would mean we couldn't extend CSS with new @-rules
that belong before @import.  (For example, an @base rule to set the
base URL, like html:base or xml:base.)

I think the argument was not to ignore @import after a valid _anything_, but after valid regular CSS rules, e.g. once you start using a selector and properties, @import should no longer import. Prior to that, though, you can (and should continue to be able to) use as many @-rules with any @-names as you want.

So, this would import "foo.css":


@blah something {
            ...
}
@bar {
            ...
}
@import "foo.css";
selector {
            prop: value;
}


...but this would not:


@blah something {
            ...
}
selector {
            prop: value;
}
@import "foo.css";



That was my understanding of it, anyway. Either way, I think that's a viable approach.

Faruk
Received on Wednesday, 11 February 2009 20:23:13 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:16 GMT