Re: [css-conditional] assigning to conditionText and calling CSS.supports()

I know you were in the room at the time, so you heard all of this, but
it's good to be clear.  All of the issues in this email have been
addressed.  (I haven't made the edits quite yet, but they were all
agreed to at the recent F2F meeting.)

On Tue, Apr 2, 2013 at 11:11 PM, Cameron McCormack <cam@mcc.id.au> wrote:
> I think the spec needs to be clearer about when the assignment of a string
> to CSSSupportsRule.conditionText should be successful and when the
> assignment should be ignored.  Currently the spec says:
>
>   If the given value matches the grammar of the appropriate condition
>   production for the given rule, replace the associated CSS condition
>   with the given value.
>
> Is this matching done strictly according to the grammar, or should the
> normal CSS parsing rules be applied?  For example with:
>
>   supportsRule.conditionText = "(color: green";
>
> the string does not strictly match the grammar, but if we think of it as
> passing the string to the CSS parser, we could invoke the special EOF
> handling behaviour that would imply the closing ")".
>
> My interpretation of CSS.supports() is that it does invoke this behaviour,
> since it talks about the string being "parsed and evaluated as a
> supports_condition".

If, as we now should, we invoke the "parse a list of component values"
algorithm, the () block will indeed be auto-closed by the
error-recovery behavior.  The spec will define that, as part of error
recovery, it actually inserts the additional required tokens into the
token stream.

> It might be strange if the conditionText attribute and CSS.supports() parsed
> condition expressions differently.
>
>
> Assuming that CSS parser EOF behaviour is meant to be invoked for
> conditionText, then we have to be careful that if we serialize the rule as a
> whole with CSSSupportsRule.cssText that you can then reparse the string and
> get the same condition.  If you do:
>
>   supportsRule.conditionText = "(color: green) /*";
>
> then you don't want supportsRule.cssText to be:
>
>   "@supports (color: green) /* {\n}"
>
> so you might need to require that the conditionText be augmented with
> whatever characters are required to have it parse the same -- in this case,
> by appending "*/".
>
> You'd need to do similar things for unclosed strings, unclosed url tokens,

Same here - comments are dropped from the stream anyway, but the rest
invoke error-recovery behavior as normal.

> and for a trailing backslash that is not inside a string or url token.

It was agreed that this case (effectively an "escaped EOF") would
tokenize as a U+FFFD REPLACEMENT CHARACTER, which can safely
round-trip.

> More difficult is what to do with a bad-string or bad-url token that is bad
> because of a trailing backslash.  For example:
>
>   supportsRule.conditionText = "(color: green) or (before: '\\";

Inside of a string or url token, an "escaped EOF" is simply dropped,
similar to an escaped newline.

> IIUC this should be the following sequence of tokens:
>
>   (
>   ident "color"
>   colon
>   whitespace
>   ident "green"
>   )
>   whitespace
>   ident "or"
>   whitespace
>   (
>   ident "before"
>   colon
>   whitespace
>   bad-string

Other than the fact that the final token is an empty string, not a
bad-string, this is now the correct behavior.

> Also, and I'm not sure if this a problem, the first step of the
> conditionText assignment says to strip white space from the string, and that
> this can cause a change of meaning with:
>
>   supportsRule.conditionText = "(counter-increment: a\\ ";
>
> if we assume that we go with option 2 above.  If we strip the white space,
> this is a parse error, as we'll encounter "\\" in the ident state, switch to
> the data state since it's followed by EOF, then flag it as a parse error.
> If we don't strip the white space, we'll have a valid ident whose value is
> "a\\".

It was agreed that Conditional is in error here - it should be
stripping whitespace *tokens* from the tokenized value, not whitespace
characters from the text.

~TJ

Received on Sunday, 9 June 2013 18:10:23 UTC