CSS telcon -- 25 Feb 2009

<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

@import

<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

issue-24

<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

- DRAFT -

CSS telcon

25 Feb 2009

Attendees

Contents

@import

issue-24

Summary of Action Items

Scribe.perl diagnostic output