See also: IRC log
<scribe> Scribe: SteveZ
Issue 51 - Core grammar for @rules conflicts with CSS3 features
issue is how to skip invalid @rules
<glazou> Bert, do the clicks I hear come from your phone ?
<Bert> I hear some soft clicks, yes.
<Bert> Should I redial?
DG: is there an issue with the object model
PL: I do not believe there is an
affect on the object model
... some browers will see an embedded @rule as an invalid selector and will gobble up to a semicolon
... others will look for matching braces following the embedded rule and will find the next style rule
... the core proposal is always parsed as an @rule no matter where you find it.
<glazou> Bert, yeah that's your phone, we can't hear you
<Bert> [ ruleset | media | page ]
BB: Instead putting "Stylesheet" as Elika suggests, we list the three cases that are allowed
<fantasai> I do not suggest that anymore
<fantasai> bjoern pointed out problems with it
<fantasai> Currently I only suggest changing the prose as described in the proposal I sent last night
PL: What you propose would not work for user defined @rules (which would be seen as invalid selectors)
PL: two issues 1) paged media
will allow embedded @rules and 2) how to handle unknown or
... I am unconvinced that Elikas proposal of last night really solves the problem; it does address the problem of embedded @rules but there is nothing to address how to parse an illegal @rule
DG: authors will understand if we throw away a well-formed @rule, but will not understand throwing away content up to a semicolon
<fantasai> http://lists.w3.org/Archives/Public/www-style/2008Jul/0581.html does handle illegal @rules, inside @media statements only however
SZ: if you find a @rule anywhere, if illegal, try to parse it as an @rule and if it is a well formed @rule then discard the whole rule and only the rule
EE: eventually, everywhere you have a style rule you should be able to put an @rule.
<fantasai> you should parse an @rule the same as outside that context
<glazou> fantasai agreed
DG: if you encounter an invalid rule, then you should not throw away the next rule.
PL: the difficulty is detecting what the next rule is
<fantasai> EE: I don't think we should change parsing rules for declaration blocks.
EE: we should limit this change to @media in 2.1 because it is the only place where stylerules are embedded in some other block.
<glazou> bert we can't hear you at all
<fantasai> EE: I think we should leave those as-is: we don't know how we want to extend that syntax in the future
<dsinger> can someone who is typing fast move the keyboard away fropm the mike (por mute)?
<Bert> The q is if we want to allow @page in @media in 2.1, (because it isn't actually forbidden anywhere...)
<fantasai> EE: but we should fix @media; I think that's the only place in CSS2.1 where we have style rules inside a block
EE: The handling of @rule throw
away is different in stylerules and declaration blocks; in the
later adding the @rule throwaway is big issue
... we could allow @rules in declarations if we require a semicolon after them
<fantasai> EE: or place them after all declarations
EE: there are no situations in 2.1 where the above is required; the need in in CSS3
<Bert> This is a pain :-(
PL: This leaves us we weird restrictions on where @rules can go or must be placed; I am not happy about that
<Bert> Everywhere where you have decalration, you *only * have decls.
<Bert> @rules were supposed to be mixed with rulesets, not decls.
<glazou> that's for now, but in the future ?
<Bert> The grammar doesn't recognize an at-rule inside a declaration, it will be a bunch of tokens which happens to start with an ATKEUWORD.
EE and BB: at issue is making a change to the core grammer
<Bert> Margin boxes inside @page were a mistake. How did that happen? :-(
MG: We know that @margin box rules in CSS3 will be affected by a change here.
<Bert> We do have options, Paged Media is not a REC yet...
<glazou> hi molly!
PL: altho adding the @rule handling to declarations would be a big change to the grammer, but it would ot be a big change to most implementations
<molly> hi glazou. Apologies for lateness, also no phone today
<fantasai> EE: If you want to push for that change, then I insist that dbaron be present for the discussion.
PL: we have consensus on handling @rules between rulesets, but we need further discussion on the handling of @rules in declartion blocks
<Bert> Don't break future extensibility! The core grammar must remain stable.
EE: can we split this into two issues: one for @rules between rulesets (@media blocks) and the second for @rules in declarations
PL: current grammer says that @rules are not allowed in rule sets so above proposal does address this problem
EE: There are two grammers; the 2.1 grammer which is helpful not authorative and the authorative grammer
<fantasai> "The grammar below defines the syntax of CSS 2.1. It is in some sense, however, a superset of CSS 2.1 as this specification imposes additional semantic constraints not expressed in this grammar. A conforming UA must also adhere to the forward-compatible parsing rules, the selectors notation, the property and value notation, and the unit notation."
<fantasai> s/the authorative grammar/the core grammar/
<glazou> SCREAM !!!
<molly> this may seem a stupid question, but what is the advantage of being able to use @rules inside a declaration?
<molly> is there a use case somewhere Elika that I can look at?
BB: is the minimal fix for this issue and it also says that @page is not allowed in @media
<sylvaing> +1 for molly's question
<fantasai> molly: we're discussing forwards-compatible parsing
<fantasai> molly: plinss is arguing that we might want to allow it in the future, and so it should be parsed in a way compatible with that possibility
<glazou> fantasai: mute pls
<fantasai> molly: bert and I are arguing that it's a big change to 2.1 and affects the core grammar, and therefore we should not change that
<molly> I'm just trying to imagine a case where that would even be necessary
<sylvaing> * is just amazed by the sound of fantasai's fierce typing
<Bert> Molly, agree 100%, but problem is that Paged Media somehow started putting @rules in front of declarations :-(
<molly> I understand the argument heh, I don't really understand the need
<fantasai> "Note: Future levels of CSS may allow at-rules in @media."
<Bert> I argued in http://lists.w3.org/Archives/Public/www-style/2008Jul/0070.html to allow @page in @media already in CSS 2.1, so that there is less diff. between 2 and 3...
SZ: the note should say that forward-compatible parsing of @rules inside at media is required to allow the the future relaxation of the restriction on @rules in @media; for example to allow @page in @media
<molly> thanks Bert, I see it now.
MG: I want to make sure that people do not test to make sure that @page does not occur in @media
<Bert> I think Melinda is saying that a UA must now choose to be CSS 2.1 or CSS3, but cannot be both, because one *must ignore* what the other *must accept*.
SZ: the problem that Melinda raises is common to forward compatible usage: something that was undefined in some context to day may be defined in the future
<Bert> Ignoring because you don't know what it measn (@foo) is diff. from ignoring because the spec says you must (@page)
<sylvaing> should the spec say you must ignore @page or define a way for CSS2.1 UAs to gracefully ignore future @xyz ?
<glazou> bye people
<molly> bye daniel!
PL and DG: allowing @page (to be processed) would make a change to the object model
All: that seems to be too big a change to 2.1
<molly> That seems dangerous to do in general, since I bet implementation will be prioritized as low by most implementers
<molly> just to allow for at-rule parsing within a declaration, that is
<Bert> Revised revised proposal (based on fantasai's): State in 7.2.1 that "@page rules inside @media are invalid in CSS2.1. Invalid at-rules inside @media blocks must be ignored per 4.2 Rules for handling parsing errors."
<molly> so the in-declaration at-rule starts its life as an at-risk feature :)
REsolution: Accept Elika's proposal with Melinda's note to not test to make sure that @page does not occur
<SaloniR> That would mean allowing embedded @media rules in CSS 2.1
<Bert> Yes, maybe we want nested @media, too :-)
Above proposed resolution was withdrawn for lack of a consensus
<Bert> Although I would be against that, but on other grounds (usability)
<molly> I thought it was a good consensus for 2.1
<molly> er, good plan
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/@rule/style rule/ Succeeded: s/will require this change/will be affected by a change here./ FAILED: s/the authorative grammar/the core grammar/ Succeeded: s/relaxation/the future relaxation/ Found Scribe: SteveZ Inferring ScribeNick: SteveZ WARNING: No "Topic:" lines found. Default Present: glazou, plinss, SteveZ, arronei, George, Bert, Melinda_Grant, [Microsoft], +1.206.324.aaaa, sylvaing, dsinger, fantasai Present: glazou plinss SteveZ arronei George Bert Melinda_Grant [Microsoft] +1.206.324.aaaa sylvaing dsinger fantasai WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 30 Jul 2008 Guessing minutes URL: http://www.w3.org/2008/07/30-css-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]