Re: [csswg-drafts] Proposal: Custom CSS Functions & Mixins (#9350)

The CSS Working Group just discussed `Proposal: Custom CSS Functions & Mixins`.

<details><summary>The full IRC log of that discussion</summary>
&lt;emeyer> TabAtkins: We agreed to take on functions &amp; mixins specification<br>
&lt;emeyer> …At this point, we have a first-draft spec for functions, but not mixins<br>
&lt;emeyer> …Not looking for resolutions, just a quick runthrough<br>
&lt;emeyer> …Custom functions are defined using an @function rule with a double-dashed identifier<br>
&lt;emeyer> …Something it resolved, a value is passed in, calculations are done, the result is passed out<br>
&lt;emeyer> …The full syntax is a little larger<br>
&lt;emeyer> …IN addition to a parameter list, there’s a dependency list<br>
&lt;emeyer> …Particularly from Lea’s feedback, it’s common to want to use defined system variables<br>
&lt;emeyer> …Having to pass them to every function is frustrating<br>
&lt;emeyer> …Functions can declare they will implicitly pull in extra variables<br>
&lt;emeyer> …Can also declare its return type<br>
&lt;emeyer> …If the custom function resolves to the wrong thing, we can detect that and act on it<br>
&lt;emeyer> …After the fact, if we see something wrong, we invalidate<br>
&lt;emeyer> …at use time<br>
&lt;lea> q+<br>
&lt;emeyer> …Just like in the other descriptor, if there are multiple results, the last one is what resolves to the value<br>
&lt;emeyer> …Conditional rules are permitted<br>
&lt;emeyer> …Things like media queries can go inside<br>
&lt;kbabbitt> draft is at https://drafts.csswg.org/css-mixins-1/<br>
&lt;emeyer> florian: Local variables, order doesn’t matter?<br>
&lt;emeyer> TabAtkins: Correct, they’re orderless<br>
&lt;emeyer> florian: I suspect this is correct, but is likely to confuse<br>
&lt;emilio> q+<br>
&lt;emeyer> TabAtkins: We hope that the fact it looks like regular styles will guide people to the right behavior<br>
&lt;emeyer> lea: SSometimes you need to access certain contexts, but the grammar looks to me like it’s easier to pass in by using<br>
&lt;emeyer> TabAtkins: You don’t pass in anything that way<br>
&lt;emeyer> …They’re automatically added to arguments at the call site<br>
&lt;emeyer> lea: It might be useful to have an aggregate syntax<br>
&lt;emeyer> TabAtkins: Please open an issue for that<br>
&lt;emeyer> s/SSometimes/Sometimes/<br>
&lt;astearns> ack lea<br>
&lt;emeyer> TabAtkins: We have a return type for the function itself<br>
&lt;lea> q+<br>
&lt;emeyer> …You can also declare grammars for individual arguments<br>
&lt;emeyer> …If you call with the wrong thing, it will invalidate the functoin<br>
&lt;emeyer> …There’s a syntax that looks like CSS grammar<br>
&lt;florian> q+ to ask what happens if you have multiple return descriptors and only one of them matches the declared type<br>
&lt;emeyer> …Authors don’t like wrapping in a string<br>
&lt;astearns> q+<br>
&lt;emeyer> …Basically, the grammar looks like custom property registrations<br>
&lt;emeyer> …There’s no change in functionality, but you don’t need to wrap in quotes<br>
&lt;lea> q+ to ask about system colors (canvas, canvastext) and currentcolor, relative units<br>
&lt;emeyer> …So you declare functions, they can use conditional queries<br>
&lt;emeyer> …If you rewrite appropriately, this should be equivalent to dropping in a nesting block<br>
&lt;Penny> (There is a noise suppression setting on the Zoom control panel set to enabled, but making changes is password protected. We'll need to engage tech support to disable it.)<br>
&lt;emeyer> …Questions?<br>
&lt;emeyer> emilio: This is a descriptor, not a property?<br>
&lt;emeyer> TabAtkins: Right<br>
&lt;emeyer> emilio: We need to sort out how this operates on the CSSOM<br>
&lt;emeyer> TabAtkins: Yeah, there could be some clashes there<br>
&lt;emeyer> emilio: This should look a lot like a style rule, right?<br>
&lt;emeyer> TabAtkins: Body will be llike a style declaration<br>
&lt;emeyer> emilio: That makes implementation... fun, but okay<br>
&lt;emeyer> s/llike/like/<br>
&lt;emeyer> lea: Making sure, system colors would resolve based on the color scheme when this is used?<br>
&lt;astearns> ack emilio<br>
&lt;astearns> ack lea<br>
&lt;Zakim> lea, you wanted to ask about system colors (canvas, canvastext) and currentcolor, relative units<br>
&lt;emeyer> TabAtkins: Yes, they’re based on the element the function is applied to<br>
&lt;matthieud> q+<br>
&lt;emeyer> …Because of the clash between functions and wider variables, vars in the body are references to (missed by scribe)<br>
&lt;astearns> ack florian<br>
&lt;Zakim> florian, you wanted to ask what happens if you have multiple return descriptors and only one of them matches the declared type<br>
&lt;lea> q+ to say the current grammar for using allows declaring types, is that intentional?<br>
&lt;emeyer> florian: If you have declared integer type and multiple returns, do you check them all against type and return the last valid or only check the last one returned against the type?<br>
&lt;emeyer> TabAtkins: I’m not sure, but I think we have flexibility<br>
&lt;fantasai> I think we want to match the type.<br>
&lt;emeyer> …We want to be consistent with other things so probably the second, but we’re not locked in either way<br>
&lt;emeyer> fantasai: I think we should take the last one that does match the type<br>
&lt;romain> +1<br>
&lt;emeyer> …They might try to do forward opt-in, which would break if we don’t do it that way<br>
&lt;kbabbitt> +1 fantasai<br>
&lt;astearns> ack astearns<br>
&lt;emeyer> astearns: The new non-string representation will also be available for custom property registration?<br>
&lt;emeyer> TabAtkins: Yes<br>
&lt;astearns> ack matthieud<br>
&lt;emeyer> matthieud: Can you only define functions at the root?<br>
&lt;emeyer> …And if it’s allowed, (missed by scribe)<br>
&lt;emeyer> TabAtkins: They are global and we don’t have a way to store the function and use it elsewhere<br>
&lt;astearns> s/(missed by scribe)/(something about closures)<br>
&lt;emeyer> lea: If they’re global only, we should not allow them to nest so we have options later<br>
&lt;emeyer> …Same for mixins, where scope is valuable<br>
&lt;fantasai> s/(missed by scribe)/can we do closures/<br>
&lt;astearns> ack lea<br>
&lt;Zakim> lea, you wanted to say the current grammar for using allows declaring types, is that intentional?<br>
&lt;emeyer> …THe using grammar allows types, is that intentional?<br>
&lt;emeyer> TabAtkins: Yes<br>
&lt;emeyer> lea: How does that work if it’s a registered variable?<br>
&lt;emeyer> TabAtkins: It still has the token representation<br>
&lt;emeyer> lea: So you could recast to a different type<br>
&lt;emeyer> TabAtkins: You can already do that by subbing<br>
&lt;keithamus> q?<br>
&lt;keithamus> q+<br>
&lt;miriam> q+<br>
&lt;astearns> ack keithamus<br>
&lt;emeyer> keithamus: Curious how these translate across shadow boundaries<br>
&lt;fantasai> s/subbing/subbing a registered variable into an unregistered variable and re-subbing into a differently-registered variable/<br>
&lt;emeyer> TabAtkins: It’s a great question<br>
&lt;emeyer> …Been thinking how to expose shadow DOM, and the answer should work but what that means exactly is undefined<br>
&lt;emeyer> …BY the time this ships we should have a reasonable answer<br>
&lt;astearns> ack miriam<br>
&lt;emeyer> miriam: Are we saying the types in the parameter list are not just for validation, they’re actually setting the type of what comes in?<br>
&lt;emeyer> TabAtkins: No, they just validate, they don’t otherwise change behavior<br>
&lt;emeyer> …We don’t have a way to trigger animations from within a function<br>
&lt;emeyer> astearns: Any other questions?<br>
&lt;emeyer> …I’m assuming this mostly spec noodling<br>
&lt;emeyer> TabAtkins: Right, nothing is imminent<br>
&lt;emeyer> astearns: Are there any resolutions you need?<br>
&lt;emeyer> TabAtkins: No<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9350#issuecomment-2377443159 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 26 September 2024 16:37:22 UTC