- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 27 Jun 2013 18:30:19 -0700
- To: "www-style@w3.org" <www-style@w3.org>
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