You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[mediaqueries][css-conditional] Allow empty functions in <general-enclosed> #6803
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.
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.
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>
Activity
andruud commentedon Nov 9, 2021
Coincidentally, we actually made a ninja-edit for this last week. #6799
tabatkins commentedon Nov 9, 2021
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 commentedon Dec 2, 2021
Reopening to get WG approval on this, since it's updating a CR. Should be routine.
css-meeting-bot commentedon Dec 15, 2021
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>