- From: Matthew Dean via GitHub <sysbot+gh@w3.org>
- Date: Thu, 24 Mar 2022 01:34:57 +0000
- To: public-css-archive@w3.org
> Though [according to its documentation](https://sass-lang.com/documentation/syntax/structure#other-expressions) Sass allows any core library or user-defined function as expression within [@if](https://sass-lang.com/documentation/at-rules/control/if). So while pure function calls without variables seem to be very uncommon according to the provided data, the CSS and Sass syntaxes for the conditions currently do clash.
This is a slippery slope. By the same token, both Less and PostCSS allow you to also define an `@if { }` and, in addition, define a function for `media()`. But, to some degree, the risk of creating a named at-rule or named CSS function is assumed by the author (vs creating something like `@-if` I guess... The CSS spec doesn't really provide good guidelines / syntax / tools to pre-processors for isolating custom syntax / custom at-rules and function calls to avoid clashes, which is part of how this whole thread got here. The JavaScript community had a similar problem with early libraries extending native prototypes, until "best practices" were established, which haven't come for CSS-related libraries.)
So you end up with something like [this PostCSS plugin](https://www.npmjs.com/package/postcss-conditionals), which has about 10,000 downloads per week.
In other words, in some sense it's good this discussion is happening, because it's clear that CSS and CSS tooling need a different approach to expanding syntax, and I think it's good that authors (and thought leaders) of CSS are taking this problem seriously.
--
GitHub Notification of comment by matthew-dean
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6684#issuecomment-1076980201 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 24 March 2022 01:35:00 UTC