[CSSWG] Minutes F2F 2013-06-05 Wed PM IV: Syntax and Conditional Rules, Variables

These are the official CSSWG minutes. Unless you're correcting the minutes,
*Please respond by starting a new thread with an appropriate subject line.*

Conditional Rules / Syntax
--------------------------

   RESOLVED: Whenever error-recovery closes open blocks, urls, strings,
             functions, brackets, etc., it implies the minimal tokens to
             close those constructs.

   RESOLVED: \[EOF] turns into U+FFFD except when inside a string, in which
             case it just gets dropped.

   RESOLVED: Clarify that badstring and baduri make @supports rules invalid

   RESOLVED: !important allowed in @supports

   RESOLVED: Publish CR with updates for CSS3 Conditional Rules

Variables
---------

   RESOLVED: Can't put unmatched ) ] }, badstring, badurl, top-level ;
             into variables

====== Full minutes below ======

Conditional Rules/Syntax
------------------------

   dbaron: Issue raised by heycam, discussed multiple times over the last month
   <stearns> http://dev.w3.org/csswg/css-conditional/doc-20130404-CR.html
   dbaron: Fun end-of-token-stream issue
   dbaron: If this is valid, we'd better put the closing tokens in the stream
   SimonSapin: Why wouldn't it be valid?
   TabAtkins: Should error-recovery add the additional necessary tokens
   plinss: I would say that error-recovery creates the necessary constructs,
           and serialization writes out the appropriate syntax.

   SimonSapin: We don't store tokens, we store component values
   dbaron: @supports rule conditions can store things that aren't valid
           values in CSS
   TabAtkins: Concept of component value he's invoking is from Syntax
   TabAtkins: It augments tokens stream into a nested tree of blocks and
              tokens and ?
   TabAtkins: We parse that into a parentheses block containing 4 tokens
   dbaron: I'm hesitant to introduce a new concept in how we specify things
   dbaron: because that might imply we need to introduce that concept into
           the implementation
   dbaron: Chances are you'll write a spec that requires the implementations
           to add that abstraction layer as a real thing

   TabAtkins: If you encouter EOF, assume the additional necessary tokens
              to assume those constructs, so that you have a well-formed
              stream
   glazou: minimal tokens necessary
   SimonSapin: You're not storing tokens, storing constructs
   SimonSapin: When you serialize it will create those constructs
   SimonSapin: Only in variables or invalid @supports conditions will you
               store tokens
   TabAtkins: So, whether store constructs or tokens streams, identical
              results
   TabAtkins: So, to answer heycam's question, this would parse correctly,
              and would imply close parens
   SimonSapin: I think in this case we don't even need to store the parens
   SimonSapin: Just need to store a declaration
   RESOLVED: Whenever error-recovery closes open blocks, urls, strings,
             functions, brackets, etc., it implies the minimal tokens to
             close those constructs.

   heycam: Related issue is \ as last character of the stream. It's valid,
           but need to add another backslash before appending anything
   TabAtkins: The backslash will become a DELIM token containing a backslash,
              and when you serialize it it will need to be escaped
   dbaron: But when you escape it, it becomes an identifier
   TabAtkins: Ahh..
   The only way to include a literal backslash is to put it as the last
   character in the stream.
   TabAtkins: Could just drop that DELIM token
   glenn: How about ident?
   glenn: In font-family has name idents
   ...
   dbaron: Another proposal, kindof random, backslash at end of stream
           converts to U+FFFD
   TabAtkins: We do the same thing to nulls
   TabAtkins: That's new behavior
   fantasai: This is a total edge case, it doesn't matter what we do here.
   plinss: Why can't it be a backslash?
   dbaron: Because you can't serialize it into any other context
   plinss: What if you have open string? Couldn't you just close the string?
   plinss: It would normally, at the end of a line, continue the string.
   dbaron: Do you want to change the rule (\[EOF]-> U+FFFD[EOF]) only for
           strings?
   plinss: Yeah
   plinss: A backslash at the end of a line inside of a string, should not
           turn into anything.
   TabAtkins: I would prefer to handle this case in the escape-handling rules.
   TabAtkins: Don't want different behavior
   dbaron: Escape behavior is already contextual wrt strings, because of \[EOL]
   plinss: Don't see any value to not just ignoring it.
   TabAtkins: OK
   RESOLVED: \[EOF] turns into U+FFFD except when inside a string, in which
             case it just gets dropped.

   heycam: If the final token in the stream is a bad-url or bad-string...
   heycam: Those are bad because you've reached the end of the file...
   heycam: If you try and fix the lone \ at the end in any way, none of
           those reserialize to a bad-string or bad-url.
   dbaron: I think Tab's revisions to Syntax fix that - you never get a
           bad-string or bad-url from EOF.
   TabAtkins: Yes, that was Zack's (original author of this stuff in 2.1)
              intention - it's an accident that 2.1 specifies two contradictory
              recovery behaviors for unclosed strings and urls.
   TabAtkins: [explains what results would be produced in various situations]

   heycam: conditionText attribute is defined to strip string of white space,
           but that could change the meaning
   heycam: shows example of escaped whitespace
   TabAtkins: need to strip whitespace tokens
   heycam: That's fine
   TabAtkins: That would be an identifier called "a "
   RESOLVED: whitespace *tokens* are stripped, not necessarily actual white
             space, from conditionText

   SimonSapin: Do we want to keep the value of badurl or badstring tokens
               around to serialize them?
   TabAtkins: Syntax right now just puts a token into the token stream,
              with no other data
   TabAtkins: Can't ever serialize them
   TabAtkins: Even variables can't use them
   ...
   SimonSapin: In @supports, we have special error-handling rule that says
               something invalid evaluates to false
   SimonSapin: But the rule is still valid
   SimonSapin: If that invalid thing is a badstring token, how do we
               serialize it?
   TabAtkins: Media queries, when serialized, serializes as a guaranteed
              false MQ?
   TabAtkins: Should do same thing with @supports?
   dbaron: I don't think we should do the same with @supports.
   dbaron: Don't think so
   dbaron: The way spec is written now, if you have badstring or baduri,
           the @supports rule will get dropped [because it doesn't match
           the grammar]
   dbaron: Maybe should call that out explicitly
   <jdaggett> ah, ok, got it
   SimonSapin: Is allowed syntax for unknown things the same as variables?
   TabAtkins: More or less
   dbaron: We should check that, but not in an F2F
   ACTION dbaron to check that variables and @supports have identical
                 allowances
   <trackbot> Created ACTION-563
   RESOLVED: Clarify that badstring and baduri make @supports rules invalid

   dbaron: Have disagreement between prose and grammar wrt !important,
           and I think grammar should be fixed
   dbaron: Think !important should be allowed there. Might add other things
           that could go there, so might as well let it be part of testable
           things.
   RESOLVED: !important allowed in @supports

   dbaron: Ok, that's all open issues. Will fix in editor's draft
   fantasai: I think the issues that require updates to Conditional Rules
             are all minor enough to be clarifications. Let's fix them and
             publish a CR in place
   RESOLVED: Publish CR with updates for CSS3 Conditional Rules

Variables
---------

   TabAtkins: Want to exclude badstring and baduri
   dbaron: And mismatched blocks
   TabAtkins: List of tokens you can't put in there: unmatched ) ] },
              badstring, badurl, top-level ;
   TabAtkins: Why is ; only disallowed at top-level, but } anywhere?
   plinss: This is error-recovery
   dbaron: Would prefer not to allow unbalanced things
   TabAtkins: Would prefer to disallow ; everywhere then
   SimonSapin, dbaron: don't see why
   dbaron: Consider in the future you want to put a declaration block in there
   ...
   TabAtkins: Ok, fine, I'm cool with this
   RESOLVED: Can't put unmatched ) ] }, badstring, badurl, top-level ;
             into variables

   http://lists.w3.org/Archives/Public/www-style/2013Apr/0246.html
   SimonSapin: Publish all the things!

Meeting closed.

<RRSAgent> http://www.w3.org/2013/06/05-css-minutes.html

Received on Friday, 28 June 2013 01:30:46 UTC