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

Minutes, CSS WG, 2009-02-25

From: Chris Lilley <chris@w3.org>
Date: Wed, 25 Feb 2009 19:24:23 +0100
Message-ID: <1286542066.20090225192423@w3.org>
To: www-style@w3.org
Hello www-style,

Minutes of the 25 Fen 2009 telcon are here

and below as text. There were two new actions, and no resolutions.

                              CSS telcon

25 Feb 2009

   See also: [2]IRC log

      [2] http://www.w3.org/2009/02/25-css-irc


          plinss, dsinger, arronei, sylvaing, ChrisL, Bert,
          David_Baron, fantasai, howcome, Melinda_Grant

          szilles, daniel, emily, molly, anne




     * [3]Topics
         1. [4]@import
         2. [5]issue-24
     * [6]Summary of Action Items

   <dsinger> Good morning ... On bus as usual

   <plinss> morning David

   <dsinger> Ah, do we have a chair?

   <plinss> yes

   <dsinger> Cool

   <dsinger> I will have to stop at 9:55 btw

   <dsinger> P10 must be fantasai?

   <scribe> scribe: chris

   <scribe> scribenick: chrisl



      [7] http://lists.w3.org/Archives/Public/www-style/2009Feb/0119.html

   cl: sent some email about multiple @rules clamouring to be 'first'

   sg: need to distinguish functionaly valid from syntactically valid

   hl: we should use the canonoical CSS syntax

   pl: agree with chris point but its not related to the current issue
   ... so the current case seems like a problem

   hl: problematic, use the eternal syntax not the css 1, 2 or 3 syntax

   db: so implementations that dont implement that currently will need
   to do so, to see if some junk fits the eternal synbtax

   ee: we don't wat to cut off extensibility

   sl: the specific test case in anne's emailis gramatically correct,
   but implementations differ

   ae: in fact it is invalid due to leading numeric

   pl: would not allow a valid rule, but would allow known or unknown

   hl: yes

   cl: i agree

   so in the anne test case, its not an @rule.

   sl: spec talks about valid statements, not @rules specifically. but
   this is not a valid statement

   hl: bert?

   bb: don't want it to load, as the rule ight be valid in the future.
   need to stop it loading

   sl: butbrowsers do load these currently

   hl: they should not

   bb: some day we may invent an @rule that has to come before an

   cl: @charset isn't an @rule

   bb: no, its special cased in the grammar

   ae: yes but its reparsed as an @rule once the charset is detected

   bb: no

   sl: spec says @import cannot come after a valid statement. but this
   is not a valid sytatement.

   bb: its correct
   ... its a normal token,

   sl: which meaning of valid do we mean here. succesfully parsed, or
   known and can be applied?

   pl: the former

   hl: we cn say there should be nothing ahead of @import except
   @charset. removes need to discuss 'valid'

   db: has anyone looked at whatwebkit does? do not want to get into
   non-interoperable behaviour
   ... what exactly does webkit to to accept or reject this @rule?

   hl: if we can agree on a simple workable solution we can test it
   against implementations

   <fantasai> db: The solution we use in Gecko is, if it parses into
   something that we know about, then we drop following @import rules

   db: in gecko, if the rule is dropped then we continue to process the

   hl: easy to flag if something has been dropped

   db: an extra semicolon at end of time - would that cause the @import
   to be dropped?

   hl: no

   ee: do you drop @import after an invalid selector? eg two commas

   <fantasai> or an unknown pseudo

   db: yes so following @import would be loaded

   bb: suggest we allow empty statements, space, cdo cdc, nothing else

   plh: its reasonable but not forward compatible

   db: properties not an issue as they are inside the rules, . error in
   selctor forces rule to be dropped

   bb: concerned about things that could be valid in the future

   db: spec id clear on rules being ignored. if spec must be ignored it
   can't trigger other things

   cl: so ignored means treat as if it was never there

   db: we have that issue witha lot of things. dont want future
   stylesheets to break completely

   pl: issue is that if the rule becomes valid tomorrow, it stops the
   @import loading

   sl: 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

   cl: how much existing content would break if the spec said nothing
   before @import?

   hl: little to none

   pl: would require changes in implementations though

   ee: any @rules that are dropped should be allowed before @import

   db: media queries changed syntax f @import. its not valid css2. so
   does non-media-queries implementsation drop?

   <dbaron> example was, given two rules: @import url(foo)
   (min-width:800px); @import url(bar);

   pl: 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

   ee: we should allow any (currently invalid) @rule before @import

   sl: invalid or unknown?

   cl: unknown

   hl: can live with

   ee: and also as bert said, empty statements and cdo cdc

   pl: odd that current @rules would block @import

   db: thats ok and we want it for forward compat

   ee: adding @rule before @import is pretty rare. less of an issue
   than withselectors

   <dbaron> so if you only allow unknown @-rules and don't allow
   anything that's not an @-rule, don't you end up distinguishing

   <dbaron> @new-rule {}

   pl: issue is known @rules not supported by older browsers

   <dbaron> @new-rule {}; /* extra semicolon at end */

   pl: covered by emptystatement rule

   db: we have a concept of empty statement?

   bb: would need to be defined in spec, but its clear

   pl: i detect consensus

   <plinss> the current proposal is: disallow any statements before
   @import except: empty statements, comment tokens, and unknown, but
   wel-formed @rules

   ee: unknown or invalid

   <fantasai> @foo;

   sl: it says unknown but wel formed

   <fantasai> @import;

   <fantasai> @namespace *;

   bb: grammar does not seem to allow empty statements

   ee: anything starting @ that has been ignored

   <dbaron> yeah, maybe the extra-semicolon thing causes the next
   selector/rule to be ignored at present

   <fantasai> that starts with an @sign

   <fantasai> @1;

   <fantasai> @import "style.css";

   ee: @1; does not parse as an at-rule

   bb: neither a selector nor an @rule

   sl: has to parse as an @rule first, then the rule is applied

   pl: so @1; would block @import

   cl: 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

   <fantasai> I agree

   dbaron - yes, but if we resolve it then someone can get an action to
   write it up in detail

   bb: (error recovery - scribe missed)

   <dbaron> I think we should action somebody to write it up without

   trackbot, status

   action; sylvian to write up the proposal on @import and unknown well
   formed @rules

   <scribe> ACTION: sylvian to write up the proposal on @import and
   unknown well formed @rules [recorded in

   <trackbot> Sorry, couldn't find user - sylvian

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

   <scribe> ACTION: sylvain to write up the proposal on @import and
   unknown well formed @rules [recorded in

   <trackbot> Created ACTION-123 - Write up the proposal on @import and
   unknown well formed @rules [on Sylvain Galineau - due 2009-03-04].

   <fantasai> [10]http://wiki.csswg.org/spec/css2.1#issue-102

     [10] http://wiki.csswg.org/spec/css2.1#issue-102

   <fantasai> [11]http://wiki.csswg.org/spec/css2.1#issue-106

     [11] http://wiki.csswg.org/spec/css2.1#issue-106


   <plinss> [12]http://wiki.csswg.org/spec/css2.1#issue-24

     [12] http://wiki.csswg.org/spec/css2.1#issue-24


   <trackbot> ISSUE-24 -- Does the 'background' shorthand needs both
   clip and origin? -- CLOSED

   <trackbot> [13]http://www.w3.org/Style/CSS/Tracker/issues/24

     [13] http://www.w3.org/Style/CSS/Tracker/issues/24

   pl: not that one

   oops,css2.1 issue not tracker issue. ignore above


     [14] http://lists.w3.org/Archives/Public/www-style/2008Nov/0509.html

   ee: 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 astatement
   not a declaration
   ... so a rue with an invalid statement will be completely ignored
   instead of justthat statement


     [15] http://lists.w3.org/Archives/Public/www-style/2008Dec/0091.html

   ee: so we need to go back and replace with 'statement
   ordeclaration'. or duplicate the rule, one for malformed statement
   and one for malformed declarations

   bb: statement or declaration is probably correct. problem is the
   section is called malformed declarations

   ee: change all occurences

   bb: would work
   ... so if you are in a declaration, skip to end of declaration
   ... yes, think its correct

   cl: so there are two proposals

   ee: scope of changes is only one paragraph

   bb: edge case, when inside a selector, if the token in error is at
   or before the start of the selector. what are you 'in'

   ee: a statement

   bb: what kind?

   ee: you don;t know at that point

   bb: so ignore that singe token?

   ee: treat it as a selector, dont ignore that token.

   bb: talking of tokens thatare disallowed by the grammar
   ... colon is allowed, better example ....
   ... closing brace for example

   ee: if its not an @rule, treat as aselector

   bb: fine with me. deals with future expansion

   pl: other opinions?

   bb: hard to follow without examples

   <dsinger> bye...another meeting, sorry

   pl: can we resolve here or do we need more discussion?

   <dbaron> (Confusion about what we would be resolving on.)

   <scribe> ACTION: bert to propose specific wording on complete text
   for what is inserted and deleted for bracket/quote parsing [recorded
   in [16]http://www.w3.org/2009/02/25-css-minutes.html#action03]

   <trackbot> Created ACTION-124 - Propose specific wording on complete
   text for what is inserted and deleted for bracket/quote parsing [on
   Bert Bos - due 2009-03-04].

   ee: is it solved with two separate rules?

   bb: not sure

   pl: why dont you two work together onthat action so it can be closed

   <dbaron> I assume no telecon next week since it'll be 2-3am between
   the first and second day of the f2f meeting

   <arronei> 253 was arronei

   <dbaron> 858 is San Diego

   dbaron, that seems a safe assumption

   <plinss> chris: 858 was me

   <dbaron> [17]http://en.wikipedia.org/wiki/Area_code_858

     [17] http://en.wikipedia.org/wiki/Area_code_858

   ok, they are both listed explicitly in the attendance list already

Summary of Action Items

   [NEW] ACTION: bert to propose specific wording on complete text for
   what is inserted and deleted for bracket/quote parsing [recorded in
   [NEW] ACTION: sylvain to write up the proposal on @import and
   unknown well formed @rules [recorded in
   [NEW] ACTION: sylvian to write up the proposal on @import and
   unknown well formed @rules [recorded in

   [End of minutes]
 Chris Lilley                    mailto:chris@w3.org
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG
Received on Wednesday, 25 February 2009 18:24:35 UTC

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