Re: [css3-conditional] value of CSSSupportsRule.conditionText

On Mon, Aug 6, 2012 at 12:16 AM, L. David Baron <dbaron@dbaron.org> wrote:
> On Sunday 2012-08-05 17:15 +1000, Cameron McCormack wrote:
>> OK.  One thing to take care with then is ensuring that additional
>> white space is inserted between number tokens (and probably some
>> others) when serializing them abutting would cause them to be
>> reparsed differently. For example with:
>>
>>   @supports (a: 1/**/.1) {}
>>
>> I think you would want the condition to be serialized either as "(a:
>> 1 .1)" or "(a: 1 0.1)" and not "(a: 1.1)" or "(a: 10.1)", even
>> though there was originally no white space token between the two
>> numbers.
>
> That might make sense in many cases, but I'm not sure it works as a
> general rule; there are places in CSS where white space between
> tokens does make a difference (in particular, in selectors:
> "div/**/p" is not a valid selector while "div p" is).

Ah, true.  Hmm, is Selectors the only place that has this issue?  I
think so - I believe everywhere else, two tokens being separated
implies that it's okay to put whitespace between them.  The problem
seems to arise from the fact that Selectors are a separate
sub-language quite unrelated to the rest of CSS syntax.

If so, we can solve this easily within Selectors - parsing the
selector can fail when it sees an IDENT IDENT starting a compound
selector, and serialization can just insert an empty comment between
them in that case.

> This case is different from anything we've seen before (although I
> expect variables will have similar issues), because we haven't
> previously had to serialize anything other than known valid syntax
> with a known meaning.  Both @supports and variables introduce the
> idea of storing arbitrary syntax, and APIs for both are likely to
> require reserializing that syntax.

I'd be fine if variables didn't preserve comments, and were serialized
with whitespace between tokens.  They can't be used for selectors, and
if you're using them for JS values and want everything preserved
literally, you should be using a string.

> I'm inclined to agree with Cameron's original suggestion that
> comments be preserved, because I don't see any other option that
> preserves arbitrary syntax so that it can be re-parsed to get the
> same result.

I think my suggestion above satisfies this requirement.

~TJ

Received on Monday, 6 August 2012 16:12:44 UTC