[mediaqueries][css-conditional] Allow empty functions in <general-enclosed>

[fantasai]

@andruud wrote in #6312 (comment)

The reason Chromium appears to evaluate not fn() to false in the demo is because not fn() is actually invalid grammar. (<any-value>, requires one or more tokens).

Since this is about forwards-compatible parsing and evaluation, it seems to me it would make more sense if <any-value> were optional so that empty functional notations would be syntactically valid.

[andruud]

Coincidentally, we actually made a ninja-edit for this last week. #6799

[tabatkins]

Yeah, the grammar was an accidental leftover from when <any-value> was implicitly optional (but this caused more confusion than it solved). It was always intended that empty functions should be allowed, and the edits are in now to reflect that.

[fantasai]

Reopening to get WG approval on this, since it's updating a CR. Should be routine.

[css-meeting-bot]

The CSS Working Group just discussed Allow empty functions in <general-enclosed>, and agreed to the following:

• RESOLVED: Accept change to allow empty functional notations in <general-enclosed>

The full IRC log of that discussion

<fantasai> Topic: Allow empty functions in <general-enclosed>
<fantasai> github: https://github.com//issues/6803
<fantasai> TabAtkins: We had some leftover grammar from a previous change that accidentally implied that if you had a <general-enclosed> in functional form it had to ahve something inside the parens
<fantasai> TabAtkins: previously could be empty
<fantasai> TabAtkins: small change to make the value optional, so that foo() would be valid
<TabAtkins> @media fn() {...}
<TabAtkins> @media fn(foo) {...}
<fantasai> TabAtkins: wanted to make sure this counts as <general-enclosed> with unknown value rather than syntax error
<fantasai> florian: asking for approval because spec is in CR
<fantasai> RESOLVED: Accept change to allow empty functional notations in <general-enclosed>