- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Sun, 08 Mar 2009 19:36:00 -0700
- To: www-style@w3.org
Summary:
- Discussed issues 102 and 106: parsing garbage and what to
do with @imports afterward.
http://wiki.csswg.org/spec/css2.1#issue-102
http://wiki.csswg.org/spec/css2.1#issue-106
- Discussed wording for issue 24; last change introduced an
error in the spec.
http://wiki.csswg.org/spec/css2.1#issue-24
====== Full minutes below ======
Attendees:
David Baron
Bert Bos
Arron Eicholz
Elika Etemad
Sylvain Galineau
Melinda Grant
Håkon Wium Lie
Chris Lilley
Peter Linss
David Singer
<RRSAgent> logging to http://www.w3.org/2009/02/25-css-irc
Scribe: Chris Lilley
@import and parsing garbage
---------------------------
<plinss> http://lists.w3.org/Archives/Public/www-style/2009Feb/0119.html
ChrisL: sent some email about multiple @rules clamouring to be 'first'
Sylvain: need to distinguish functionaly valid from syntactically valid
howcome: we should use the canonoical CSS syntax
Peter: agree with chris point but its not related to the current issue
... so the current case seems like a problem
howcome: problematic, use the core syntax not the css 1, 2 or 3 syntax
dbaron: so implementations that don't implement that currently will need
to do so, to see if some junk fits the core syntax
fantasai: we don't want to cut off extensibility
Sylvain: the specific test case in anne's emailis gramatically correct,
but implementations differ
Arron: in fact it is invalid due to leading numeric
Peter: would not allow a valid rule, but would allow known or unknown @rules.
howcome: yes
ChrisL: i agree
so in the anne test case, its not an @rule.
Sylvain: spec talks about valid statements, not @rules specifically. but
this is not a valid statement
howcome: bert?
Bert: don't want it to load, as the rule might be valid in the future.
need to stop it loading
Sylvain: but browsers do load these currently
howcome: they should not
Bert: some day we may invent an @rule that has to come before an @import
ChrisL: @charset isn't an @rule
Bert: no, its special cased in the grammar
Arron: yes but its reparsed as an @rule once the charset is detected
Bert: no
Sylvain: spec says @import cannot come after a valid statement. but this is
not a valid sytatement.
Bert: its correct
Bert: its a normal token,
Sylvain: which meaning of valid do we mean here. succesfully parsed, or known
and can be applied?
Peter: the former
howcome: we can say there should be nothing ahead of @import except @charset.
removes need to discuss 'valid'
dbaron: has anyone looked at whatwebkit does? do not want to get into
non-interoperable behaviour
.. what exactly does webkit do to accept or reject this @rule?
howcome: if we can agree on a simple workable solution we can test it against
implementations
dbaron: The solution we use in Gecko is, if it parses into something that we
know about, then we drop following @import rules
howcome: easy to flag if something has been dropped
dbaron: an extra semicolon at end of time - would that cause the @import to
be dropped?
howcome: no
fantasai: do you drop @import after an invalid selector? eg two commas
<fantasai> or an unknown pseudo
dbaron: yes so following @import would be loaded
Bert: suggest we allow empty statements, space, cdo cdc, nothing else
Peter: its reasonable but not forward compatible
dbaron: properties not an issue as they are inside the rules, . error in
selector forces rule to be dropped
Bert: concerned about things that could be valid in the future
dbaron: spec id clear on rules being ignored. if spec must be ignored it
can't trigger other things
ChrisL: so ignored means treat as if it was never there
dbaron: we have that issue with a lot of things. don't want future
stylesheets to break completely
Peter: issue is that if the rule becomes valid tomorrow, it stops the @import
loading
Sylvain: this can happen today, ie8 does not support :: for example so
following import will load but later, or in other browsers, it will
be skipped
ChrisL: how much existing content would break if the spec said nothing before
@import?
howcome: little to none
Peter: would require changes in implementations though
fantasai: any @rules that are dropped should be allowed before @import
dbaron: media queries changed syntax of @import. its not valid css2. so does
non-media-queries implementations drop?
<dbaron> example was, given two rules: @import url(foo) (min-width:800px);
@import url(bar);
Peter: there are implementations that do not support media queries
<dbaron> implementations without media queries skip the first; with this
change would we also require them to skip the second?
<fantasai> I strongly believe that we should allow dropped @rules before
@import
fantasai: we should allow any (currently invalid) @rule before @import
Sylvain: invalid or unknown?
ChrisL: unknown
howcome: can live with
fantasai: and also as bert said, empty statements and cdo cdc
Peter: odd that current @rules would block @import
dbaron: thats ok and we want it for forward compat
fantasai: adding @rule before @import is pretty rare. less of an issue than
with selectors
Peter: issue is known @rules not supported by older browsers
<dbaron> so if you only allow unknown @-rules and don't allow anything that's
not an @-rule, don't you end up distinguishing between:
<dbaron> @new-rule {}
<dbaron> @new-rule {}; /* extra semicolon at end */
Peter: covered by emptystatement rule
dbaron: we have a concept of empty statement?
Bert: would need to be defined in spec, but its clear
Peter: i detect consensus
<plinss> the current proposal is: disallow any statements before @import
except: empty statements, comment tokens, and unknown, but
well-formed @rules
fantasai: unknown or invalid
<fantasai> @foo;
Sylvain: it says unknown but well formed
<fantasai> @import;
<fantasai> @namespace *;
Bert: grammar does not seem to allow empty statements
fantasai: anything starting with @ that has been ignored
<dbaron> yeah, maybe the extra-semicolon thing causes the next selector/rule
to be ignored at present
<fantasai> @1;
<fantasai> @import "style.css";
fantasai: @1; does not parse as an at-rule
Bert: neither a selector nor an @rule
Sylvain: has to parse as an @rule first, then the rule is applied
Peter: so @1; would block @import
ChrisL: yes
(no objection heard)
<dbaron> I think it would be good to see the proposal actually written up.
<dbaron> This is rather hard to follow with lots of abstract statements.
<fantasai> I agree
dbaron - yes, but if we resolve it then someone can get an action to write
it up in detail
Bert: (error recovery - scribe missed)
<dbaron> I think we should action somebody to write it up without resolving.
ACTION: Sylvain to write up the proposal on @import and unknown well formed
@rules
<Bert> (Issue 24 is about recovering from invalid tokens when inside a
selector. The ; in @1; is such an invalid token. What to do? Skip to
the next {}?)
<fantasai> http://wiki.csswg.org/spec/css2.1#issue-102
<fantasai> http://wiki.csswg.org/spec/css2.1#issue-106
Brackets and Error Handling
---------------------------
<plinss> http://wiki.csswg.org/spec/css2.1#issue-24
<fantasai> http://lists.w3.org/Archives/Public/www-style/2008Nov/0509.html
fantasai: we wanted to requie matching brackets, the change we made to fix
this solves selectors but adds a new problem for declarations
... makes the trap point for an invalid declaration to be a statement not a
declaration
... so a rule with an invalid statement will be completely ignored instead of
just that statement
<fantasai> http://lists.w3.org/Archives/Public/www-style/2008Dec/0091.html
fantasai: so we need to go back and replace with 'statement ordeclaration'.
or duplicate the rule, one for malformed statement and one for
malformed declarations
Bert: statement or declaration is probably correct. problem is the section
is called malformed declarations
fantasai: change all occurences
Bert: would work
Bert: so if you are in a declaration, skip to end of declaration
Bert: yes, think its correct
ChrisL: so there are two proposals
fantasai: scope of changes is only one paragraph
Bert: edge case, when inside a selector, if the token in error is at or
before the start of the selector. what are you 'in'
fantasai: a statement
Bert: what kind?
fantasai: you don't know at that point
Bert: so ignore that singe token?
fantasai: treat it as a selector, don't ignore that token.
Bert: talking of tokens that are disallowed by the grammar
Bert: colon is allowed, better example ....
... closing brace for example
fantasai: if its not an @rule, treat as aselector
Bert: fine with me. deals with future expansion
Peter: other opinions?
Bert: hard to follow without examples
<dsinger> bye...another meeting, sorry
Peter: can we resolve here or do we need more discussion?
<dbaron> (Confusion about what we would be resolving on.)
ACTION: bert to propose specific wording on complete text for what is
inserted and deleted for bracket/quote parsing
fantasai: is it solved with two separate rules?
Bert: not sure
Peter: why don't you two work together on that action so it can be closed
quickly
<RRSAgent> I have made the request to generate http://www.w3.org/2009/02/25-css-minutes.html ChrisL
Received on Monday, 9 March 2009 02:36:48 UTC