See also: IRC log
<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
<plinss> 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 @rules.
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 @import
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 @rule
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 between:
<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 statements.
<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 resolving.
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 http://www.w3.org/2009/02/25-css-minutes.html#action01]
<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 http://www.w3.org/2009/02/25-css-minutes.html#action02]
<trackbot> Created ACTION-123 - Write up the proposal on @import and unknown well formed @rules [on Sylvain Galineau - due 2009-03-04].
<fantasai> http://wiki.csswg.org/spec/css2.1#issue-102
<fantasai> http://wiki.csswg.org/spec/css2.1#issue-106
<plinss> http://wiki.csswg.org/spec/css2.1#issue-24
issue-24?
<trackbot> ISSUE-24 -- Does the 'background' shorthand needs both clip and origin? -- CLOSED
<trackbot> http://www.w3.org/Style/CSS/Tracker/issues/24
pl: not that one
oops,css2.1 issue not tracker issue. ignore above
<fantasai> 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
<fantasai> 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 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 quickly
<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> http://en.wikipedia.org/wiki/Area_code_858
ok, they are both listed explicitly in the attendance list already
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/allowed/loaded/ Succeeded: s/stements/statements/ Succeeded: s/anything/anything starting @/ Succeeded: s/ifnore/ignore/ Succeeded: s/bb;/bb:/g Succeeded: s/sl;/sl:/g Succeeded: s/pl;/pl:/g Succeeded: s/db;/db:/g Succeeded: s/hl;/hl:/g Found Scribe: chris Found ScribeNick: chrisl WARNING: Replacing list of attendees. Old list: +1.253.307.aaaa New list: +1.858.354.aaaa plinss dsinger +1.253.307.aabb arronei sylvaing ChrisL Bert David_Baron fantasai? howcome Melinda_Grant Default Present: +1.858.354.aaaa, plinss, dsinger, +1.253.307.aabb, arronei, sylvaing, ChrisL, Bert, David_Baron, fantasai?, howcome, Melinda_Grant Present: plinss dsinger arronei sylvaing ChrisL Bert David_Baron fantasai howcome Melinda_Grant Regrets: szilles daniel emily molly anne Got date from IRC log name: 25 Feb 2009 Guessing minutes URL: http://www.w3.org/2009/02/25-css-minutes.html People with action items: bert sylvain sylvian[End of scribe.perl diagnostic output]