- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 25 Mar 2026 15:14:22 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-mixins-1] Mixins can be called (but not defined) without params`, and agreed to the following: * `RESOLVED: Allow mixin definitions to drop the parentheses for consistency` <details><summary>The full IRC log of that discussion</summary> <kbabbitt> TabAtkins: anders raised the isue that while the mixing calling syntax can call a mixin with or without parens<br> <kbabbitt> ... if you don't put them, it's the same as calling with an empty arg list<br> <kbabbitt> ... but you can't define a mixin without an arg list<br> <kbabbitt> ... even if it doesn't take any params, grammar requires ()<br> <kbabbitt> ... reason why I allowed omitting parens at call site was to match Sass, seems reasonable for things that don't take args<br> <lea> q+<br> <kbabbitt> ... missed that Sass also lets you omit at definition site<br> <kizu> q+<br> <kbabbitt> ..., I'm happy either way, there's an argument for making them both omit to match Sass<br> <kbabbitt> ... but Sorvell also said, he thinks it's useful to always have () at definition syntax<br> <kbabbitt> ... to emphasize it's something called, not a construct that floats around<br> <kbabbitt> ... a call similar to a function<br> <kbabbitt> ... and functions require () at both sites<br> <miriam> q+<br> <kbabbitt> ... I don't care which way we go, happy to close no change but happy to make them consistent if there are strong opinions<br> <astearns> ack lea<br> <kbabbitt> lea: not a particularly strong opinion since it's just two extra chars but generally in favor of improving signal to noise and with no params these are just noise<br> <kbabbitt> ... in favor of removing, think it's more important to be consistent between call site and definition<br> <fantasai> +1 to consistency<br> <kbabbitt> ... then question, do we always include or allow either way<br> <kbabbitt> ... mildly in favor of allowing either way<br> <kbabbitt> +1 lea<br> <astearns> ack kbabbitt<br> <astearns> ack kizu<br> <kbabbitt> kizu: next issue is about macros, but macros have no args<br> <kbabbitt> ... will be defined without but will be called same way<br> <kbabbitt> ... so I don't think it makes much sense to include parens<br> <kbabbitt> ... either way I think we need to think about this for both macros and mixins, defined differentlybut called the same way<br> <kbabbitt> ... would be in favor of allowing them to be omitted<br> <kbabbitt> ... at call site you already use @apply, in JS parens means extra signal but when you call @apply you're already signaling you're calling something<br> <astearns> ack miriam<br> <kbabbitt> miriam: also lightly in favor of not needing them in either place<br> <kbabbitt> ... more strongly in favor of having them match<br> <kbabbitt> ... so if we require in one place, require in both<br> <kbabbitt> ... sorvell's argument makes more sense for call site than definition site<br> <kbabbitt> ... we want to know this is function like when we call it<br> <kbabbitt> ... if we're taking his argument, we should require it both places<br> <kbabbitt> ... slightly in favor of the other<br> <astearns> ack fantasai<br> <kbabbitt> fantasai: also agree with consistency<br> <kbabbitt> ... unsure whether we should require parens or not<br> <kbabbitt> ... it's the same thing fundamentally, having same syntax makes sense to me, don't feel strongly about that<br> <kbabbitt> ... as long as we're not closing ourselves off to some future addition we might want, that would be main concern with making it optional<br> <kbabbitt> astearns: fantasai made me wonder one things, if you define a mixin with params, can they be given a default?<br> <kbabbitt> TabAtkins: yes, just like custom functions, params can receive defaults<br> <kbabbitt> astearns: so a mixin could have aprams but if you don't need params you could have a call site with no parens and that would mean use defaults?<br> <kbabbitt> TabAtkins: yes that's what the spec says today<br> <kbabbitt> ... sounds like there's generally weak agreement that we should at least be consistent and slightly weaker that we allow them to be omitted in both sites<br> <kbabbitt> ... I'm fine with that<br> <kbabbitt> TabAtkins: Proposed resolution: We allow omitting parentheses from a mixin definition, that's the same as an empty arg list<br> <kbabbitt> astearns: to kizu's point, is that consistent with macros?<br> <kbabbitt> TabAtkins: yes<br> <kbabbitt> ... macro consistency is maintained as long as we don't require parens at call site<br> <kbabbitt> ... macros will never take args but in spec right now you call mixins and macros the same way, can pass an empty arg list<br> <kbabbitt> astearns: Proposed: Allow mixin definitions to drop the parentheses for consistency<br> <kbabbitt> ... objections?<br> <kbabbitt> RESOLVED: Allow mixin definitions to drop the parentheses for consistency<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13015#issuecomment-4127410977 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 25 March 2026 15:14:22 UTC