Proposal: first-class support for CSS Functions #3446
Conversation
| Note that if an argument is a number or a nested calculation, it’s returned as | ||
| that type. Otherwise, it’s returned as an unquoted string. | ||
|
|
||
| ## Syntax |
There was a problem hiding this comment.
Looking for guidance on the Syntax section
There was a problem hiding this comment.
Since this proposal doesn't actually change the grammar of CSS functions, you don't need a syntax section. You'll just refer to the syntax already defined for functions.
| To serialize a CSS Function, emit its name followed by "(", then each of its | ||
| arguments separated by ",", then ")". | ||
|
|
||
| ## Semantics |
There was a problem hiding this comment.
Looking for guidance on the Semantics section
There was a problem hiding this comment.
This is where you describe how to create a CSS function value given the syntax. You can think of this as describing the difference between the current semantics and the way you want it to work.
|
|
||
| * If `arg` is a number or a calculation, add it to `args`. | ||
|
|
||
| * Otherwise, [serialize](#serialization) `arg` and add the result to `args` as |
There was a problem hiding this comment.
How would this handle the newer space and slash-separated rgb($red $green $blue / $alpha) syntax?
There was a problem hiding this comment.
Those would just be considered single-argument functions whose first argument is a list (slash-separated in this case once we finish deprecating /-as-division).
There was a problem hiding this comment.
One important thing to note here: for backwards-compatibility, I think it's very important that we continue to have CSS functions act like strings, since the only way existing users have to extract information about them is through string functions. Specifically, this means that all the string functions should have a clause added to them that says "if the argument is a CSS function, serialize it and then do the string function on the result".
| Note that if an argument is a number or a nested calculation, it’s returned as | ||
| that type. Otherwise, it’s returned as an unquoted string. | ||
|
|
||
| ## Syntax |
There was a problem hiding this comment.
Since this proposal doesn't actually change the grammar of CSS functions, you don't need a syntax section. You'll just refer to the syntax already defined for functions.
| type CssFunctionArgument = | ||
| | Number | ||
| | UnquotedString | ||
| | Calculation; |
There was a problem hiding this comment.
Why these three specific values? Shouldn't a plain CSS function allow any value?
| To serialize a CSS Function, emit its name followed by "(", then each of its | ||
| arguments separated by ",", then ")". | ||
|
|
||
| ## Semantics |
There was a problem hiding this comment.
This is where you describe how to create a CSS function value given the syntax. You can think of this as describing the difference between the current semantics and the way you want it to work.
|
|
||
| * If `arg` is a number or a calculation, add it to `args`. | ||
|
|
||
| * Otherwise, [serialize](#serialization) `arg` and add the result to `args` as |
There was a problem hiding this comment.
Those would just be considered single-argument functions whose first argument is a list (slash-separated in this case once we finish deprecating /-as-division).
|
Ideally, I'd also like to have a JS API type added for this as well. We've been falling behind on ensuring the JS API supports all Sass value types, so I'd like to avoid furthering that problem here. |
This proposal changes all CSS Functions from being parsed as unquoted strings to being parsed in-depth and producing a new data type known as a "css-function". This data type holds the name and arguments of the function.