value of CSSSupportsRule.conditionText

It's not exactly clear to me what should be included in conditionText 
when it comes to white space and comments.  For example, with:

   @supports (a: b) {}

My guess is that we would want to return "(a: b)" rather than "(a: b )" 
or " (a: b) ".  But looking at the grammar, I think supports_condition 
should actually include the trailing white space since there a "S*" at 
the end of each production.  So I think the spec should say to trim 
white space of the string that is returned.

But comments should probably stay, since if you think there is 
implicitly a COMMENT* between after each other symbol in the grammar 
then it would be included in the supports_condition, and it isn't as 
simple to trim comments from the string.  So for:

   @supports /*1*/ (a: b) /*2*/ {}

I think it should return "(a: b) /*2*/".

Le 04/08/12 06:51, Cameron McCormack a écrit :
> It's not exactly clear to me what should be included in conditionText
> when it comes to white space and comments. For example, with:
>
> @supports (a: b) {}
>
> My guess is that we would want to return "(a: b)" rather than "(a: b )"
> or " (a: b) ". But looking at the grammar, I think supports_condition
> should actually include the trailing white space since there a "S*" at
> the end of each production. So I think the spec should say to trim white
> space of the string that is returned.
>
> But comments should probably stay, since if you think there is
> implicitly a COMMENT* between after each other symbol in the grammar
> then it would be included in the supports_condition, and it isn't as
> simple to trim comments from the string. So for:
>
> @supports /*1*/ (a: b) /*2*/ {}
>
> I think it should return "(a: b) /*2*/".No. None of our existing serializations outputs comments and I don't
see why we should start here. In current implementations, comments
are usually stripped at parse time anyway by the lexer.

</Daniel>

On Sat, Aug 4, 2012 at 12:26 PM, Daniel Glazman
 wrote:
> Le 04/08/12 06:51, Cameron McCormack a écrit :
>
>> It's not exactly clear to me what should be included in conditionText
>> when it comes to white space and comments. For example, with:
>>
>> @supports (a: b) {}
>>
>> My guess is that we would want to return "(a: b)" rather than "(a: b )"
>> or " (a: b) ". But looking at the grammar, I think supports_condition
>> should actually include the trailing white space since there a "S*" at
>> the end of each production. So I think the spec should say to trim white
>> space of the string that is returned.
>>
>> But comments should probably stay, since if you think there is
>> implicitly a COMMENT* between after each other symbol in the grammar
>> then it would be included in the supports_condition, and it isn't as
>> simple to trim comments from the string. So for:
>>
>> @supports /*1*/ (a: b) /*2*/ {}
>>
>> I think it should return "(a: b) /*2*/".
>
>
> No. None of our existing serializations outputs comments and I don't
> see why we should start here. In current implementations, comments
> are usually stripped at parse time anyway by the lexer....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).

~TJ

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.

On Sun, Aug 5, 2012 at 12:15 AM, 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.Good point.  I'll put an issue in Syntax for this.

~TJ

Le 05/08/12 22:12, Tab Atkins Jr. a écrit :

>>    @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.
>
> Good point.  I'll put an issue in Syntax for this.Given that comments are allowed anywhere between tokens but not inside
tokens, that should already be the case, right?

</Daniel>

Le 06/08/2012 08:43, Daniel Glazman a écrit :
> Le 05/08/12 22:12, Tab Atkins Jr. a écrit :
>>>     @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.
>>
>> Good point.  I'll put an issue in Syntax for this.
> Given that comments are allowed anywhere between tokens but not inside
> tokens, that should already be the case, right?The problem is when serializing tokens to a CSS string. Some tokens can 
not be written next to each other because they would not have the same 
meaning when tokenized again.

The example is 1/**/.1
If the tokenizer ignores comments, it will give two NUMBER tokens. 
Serializing them naively gives 1.1, which is now a single token with a 
different meaning.

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.

-David

On Mon, 06 Aug 2012 09:16:01 +0200, L. David Baron   
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

(12/08/06 15:16), L. David Baron wrote:
> 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 reminds me that css3-animations and css3-conditional probably
shouldn't require spaces after ATKEYWORD. Namely,

  keyframes_rule: KEYFRAMES_SYM S+ IDENT S* '{' S* keyframes_blocks '}'
      S*
    ;

in css3-animations and

  supports_rule
  : SUPPORTS_SYM S+ supports_condition group_rule_body
  ;

and

document_rule
  : DOCUMENT_SYM S+ url_match_fn ( "," S* url_match_fn )*
    group_rule_body
  ;

in css3-conditional should undergo a s/S+/S*/. Note that, according to
CSS 2.1 Appendix G, @media has

media
  : MEDIA_SYM S* media_list '{' S* ruleset* '}' S*
  ;

and every browser implements this (tested with:

  data:text/html,<style>@media/**/all { body { background: green; }
}</style>

on IE9, Firefox 14, Chrome 21 and Opera 12.50 internal). Firefox 14,
Chrome 21 and Opera 12.50 implement S* instead of S+ for @keyframes too,
and I would be very shocked if IE 10 does S+...

(tested with

  data:text/html,<style>@keyframes/**/test {from{background: green}
to{background: green}} body {animation: test infinite 1s;}</style>
)

I think css3-syntax should have normative statement about this as it's
not a good idea to reason based on something we intend to make
deprecated, namely, CSS 2.1 Appendix G.


Cheers,
Kenny

On Mon, Aug 6, 2012 at 3:54 AM, Kang-Hao (Kenny) Lu
 wrote:
> (12/08/06 15:16), L. David Baron wrote:
>> 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 reminds me that css3-animations and css3-conditional probably
> shouldn't require spaces after ATKEYWORD. Namely,[snip]> I think css3-syntax should have normative statement about this as it's
> not a good idea to reason based on something we intend to make
> deprecated, namely, CSS 2.1 Appendix G.Is a statement actually required in Syntax?  This falls out of the
definition of the tokenizer - there are a lot of places where a
comment can be inserted between things to separate tokens, where
whitespace would otherwise be required.

What I would like to do in Syntax, though, is provide more grammar
primitives a la property definitions, so that at-rules can be defined
more abstractly without having to worry about the details of the
tokenizer.

~TJ

(12/08/07 0:01), Tab Atkins Jr. wrote:
> On Mon, Aug 6, 2012 at 3:54 AM, Kang-Hao (Kenny) Lu
>  wrote:
>> (12/08/06 15:16), L. David Baron wrote:
>>> 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 reminds me that css3-animations and css3-conditional probably
>> shouldn't require spaces after ATKEYWORD. Namely,
> [snip]
>> I think css3-syntax should have normative statement about this as it's
>> not a good idea to reason based on something we intend to make
>> deprecated, namely, CSS 2.1 Appendix G.
> 
> Is a statement actually required in Syntax?  This falls out of the
> definition of the tokenizer - there are a lot of places where a
> comment can be inserted between things to separate tokens, where
> whitespace would otherwise be required.
> 
> What I would like to do in Syntax, though, is provide more grammar
> primitives a la property definitions, so that at-rules can be defined
> more abstractly without having to worry about the details of the
> tokenizer.That's fine as long as mediaqueries4 defines @media. It currently
doesn't supposedly because Media Queries was thought of as something CSS
independent and @media was intentionally left to CSS 2.1, and the
details of the syntax in Appendix G.

Now that Appendix G and all syntax related parts in CSS 2.1 are supposed
to be deprecated by css3-syntax, we can reconsider that. In the
meanwhile, I would suggest css3-syntax actively try to cover this part
before some coordination between mediaqueries4 and css3-syntax happen.



Cheers,
Kenny

On Mon, Aug 6, 2012 at 12:16 AM, L. David Baron  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

On Monday 2012-08-06 09:11 -0700, Tab Atkins Jr. wrote:
> On Mon, Aug 6, 2012 at 12:16 AM, L. David Baron  wrote:
> > 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.I don't see how it helps.

In particular, I think it would probably be a good idea if
serialization rules we came up with for variables or @supports were
able to handle some of the contents being selectors rather than
property values -- and to do so correctly without knowing whether
the contents were selectors or property values.

Otherwise I worry we'd have trouble extending these concepts to
cover selectors if we wanted to do so in the future.

-David

On Mon, Aug 6, 2012 at 9:47 AM, L. David Baron  wrote:
> On Monday 2012-08-06 09:11 -0700, Tab Atkins Jr. wrote:
>> On Mon, Aug 6, 2012 at 12:16 AM, L. David Baron  wrote:
>>> 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.
>
> I don't see how it helps.
>
> In particular, I think it would probably be a good idea if
> serialization rules we came up with for variables or @supports were
> able to handle some of the contents being selectors rather than
> property values -- and to do so correctly without knowing whether
> the contents were selectors or property values.
>
> Otherwise I worry we'd have trouble extending these concepts to
> cover selectors if we wanted to do so in the future.Actually, it'll still work even if we do make it apply to selectors in
the future.  The only problem is reserializing, which is easy to
detect and insert an empty comment for, as I proposed.

~TJ

Tab Atkins Jr.:> Actually, it'll still work even if we do make it apply to selectors in
> the future.  The only problem is reserializing, which is easy to
> detect and insert an empty comment for, as I proposed.But it doesn't work if you want to allow selectors (or other syntax 
sensitive to a lack of white space between tokens) inside the supports 
condition.  For example with a hypothetical:

   @supports (foopy: select(#a/**/.b/**/)) { ... }

There's no way to know that the comment before the "." needs to be 
preserved while the one after the "b" can be dropped, if your UA doesn't 
implement foopy.  So we would need to preserve all comments within the 
property value parts of the supports condition, at least.

On Mon, Aug 6, 2012 at 5:05 PM, Cameron McCormack  wrote:
> Tab Atkins Jr.:
>> Actually, it'll still work even if we do make it apply to selectors in
>> the future.  The only problem is reserializing, which is easy to
>> detect and insert an empty comment for, as I proposed.
>
> But it doesn't work if you want to allow selectors (or other syntax
> sensitive to a lack of white space between tokens) inside the supports
> condition.  For example with a hypothetical:
>
>   @supports (foopy: select(#a/**/.b/**/)) { ... }
>
> There's no way to know that the comment before the "." needs to be preserved
> while the one after the "b" can be dropped, if your UA doesn't implement
> foopy.  So we would need to preserve all comments within the property value
> parts of the supports condition, at least.Ah, yes, I see.  You can only trigger the special "insert a comment"
rule if you know that you're in a selector context, and we'd like to
avoid requiring that knowledge.

Okay, then yeah, comments will need to be preserved (at least the
presence of them, though not their contents), unless we change the
rule that allows comments there in the first place. ^_^

~TJ

On Tue, 07 Aug 2012 02:19:07 +0200, Tab Atkins Jr.   
wrote:
> Ah, yes, I see.  You can only trigger the special "insert a comment"
> rule if you know that you're in a selector context, and we'd like to
> avoid requiring that knowledge.
>
> Okay, then yeah, comments will need to be preserved (at least the
> presence of them, though not their contents), unless we change the
> rule that allows comments there in the first place. ^_^Rather than write fancy serialization rules that modify a string
we don't know how to interpret in ways we hope will not modify it's
interpretation, I think just preserving the string as it was in the
stylesheet is by far the easiest and foolproof approach.

  - Florian

Le 06/08/2012 18:11, Tab Atkins Jr. a écrit :
> 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.What about !important ?  Is this valid?  ! /**/ important

Le 06/08/12 19:41, Simon Sapin a écrit :
> Le 06/08/2012 18:11, Tab Atkins Jr. a écrit :
>> 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.
>
> What about !important ? Is this valid? ! /**/ importantCSS 2.1 grammar says:

  "!"({w}|{comment})*{I}{M}{P}{O}{R}{T}{A}{N}{T}	{return IMPORTANT_SYM;}

So, yes.

</Daniel>