- From: Brandon McConnell via GitHub <sysbot+gh@w3.org>
- Date: Thu, 04 Jul 2024 03:39:14 +0000
- To: public-css-archive@w3.org
@mirisuzanne I was reading back over some updates in your official proposal under the ["Other result syntaxes for functions" section](https://css.oddbird.net/sasslike/mixins-functions/#other-result-syntaxes-for-functions). While I see the value in using a property-like keyword like `result`, I do see some possible reason for concern in that over a `@return` at-rule. A special function-definition-specific `result` property would follow many of the same conventions as the cascade, and one might think specificity would come into play here as well, though I'm not sure that would be a factor based on the implications of this paragraph of the ["Function rules" section](https://css.oddbird.net/sasslike/mixins-functions/#function-rules): > As far as I can tell, only custom properties, args/variables, and conditional rules are useful inside a function definition. Functions have no output besides their returned value, so nested selectors, built-in properties, and name-defining rules are not necessary or meaningful. I don’t think there’s any need for these things to invalidate the entire function, but they should be ignored and discarded. If specificity plays no role in functions, then we can forget my concern here, but if it does, I think there may be some reasoning left around how we handle situations where users want a certain condition bearing lower specificity to take precedence over a condition of higher specificity. Thanks for all your work on this! -- GitHub Notification of comment by brandonmcconnell Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9350#issuecomment-2208064597 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 4 July 2024 03:39:15 UTC