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

[CSSWG] Minutes and Resolutions 2009-02-25

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sun, 08 Mar 2009 19:36:00 -0700
Message-ID: <49B48090.9010705@inkedblade.net>
To: www-style@w3.org

   - Discussed issues 102 and 106: parsing garbage and what to
     do with @imports afterward.

   - Discussed wording for issue 24; last change introduced an
     error in the spec.

====== Full minutes below ======

   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
   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
   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
   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
   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
   <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
   ... 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
   <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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:49:26 UTC