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

On Mon, 06 Aug 2012 09:16:01 +0200, L. David Baron <dbaron@dbaron.org>  
wrote:

> On Sunday 2012-08-05 17:15 +1000, Cameron McCormack wrote:
>> Tab Atkins Jr.:
>> >...which Syntax also specifies. Everything here will be a bit simpler
>> >once I finish up Syntax, as we'll have a clear and definite answer to
>> >these kinds of questions (or at least a clear and definite base from
>> >which to make alterations from).
>>
>> 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).
>
> 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'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 agree that this is special due to the fact that we're trying
to serialize potentially unknown syntax.

I would say that:

* outside of "'(' S* core_declaration ')'", spaces and comments should be  
dropped, and we should serialize into a normalized form with minimal  
whitespace. Simplifying "(((((a:b)))))" into "(a:b)" would also be  
reasonable. Possibly also "not (not (a:b))" into "(a:b)".

* inside, the simplest and safest is to simply preserve everything, and  
return the exact string used in the style sheet. We may want to trim white  
space and comments that come before the property name or after the end of  
the value, but I am not even sure about that.

  - Florian

Received on Monday, 6 August 2012 10:17:52 UTC