- 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