- From: Chris Lilley <chris@w3.org>
- Date: Wed, 25 Feb 2009 19:24:23 +0100
- To: www-style@w3.org
Hello www-style, Minutes of the 25 Fen 2009 telcon are here http://www.w3.org/2009/02/25-css-minutes.html 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 Attendees Present plinss, dsinger, arronei, sylvaing, ChrisL, Bert, David_Baron, fantasai, howcome, Melinda_Grant Regrets szilles, daniel, emily, molly, anne Chair Peter Scribe chris Contents * [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 @import <plinss> [7]http://lists.w3.org/Archives/Public/www-style/2009Feb/0119.html [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 @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 [8]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 [9]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> [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 issue-24 <plinss> [12]http://wiki.csswg.org/spec/css2.1#issue-24 [12] 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> [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 <fantasai> [14]http://lists.w3.org/Archives/Public/www-style/2008Nov/0509.html [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 <fantasai> [15]http://lists.w3.org/Archives/Public/www-style/2008Dec/0091.html [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 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> [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 [18]http://www.w3.org/2009/02/25-css-minutes.html#action03] [NEW] ACTION: sylvain to write up the proposal on @import and unknown well formed @rules [recorded in [19]http://www.w3.org/2009/02/25-css-minutes.html#action02] [NEW] ACTION: sylvian to write up the proposal on @import and unknown well formed @rules [recorded in [20]http://www.w3.org/2009/02/25-css-minutes.html#action01] [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