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

@JaneOri 

It's probably worth its own breakout thread / discussion for CSS to define, in spec, just what a list _is_, and how / when it's delimited in one way vs. another. As far as I know, there's no syntactic explanation; CSS is mostly a collection of micro-syntaxes that mostly conform to another, and depending on when a property / value set was introduced, can have slightly different syntactic conventions. So there are rough intuitive understandings of when something is a space-separated vs. comma-separated vs. slash-separated list vs. semi-colon separated, but unless I've missed it in the time I've spent with CSS specs, there's not really a theory of the syntax that really explains it... and then on the "function-like" side of things, the semantics of comma-separated lists (distinct argument values) is ever-so-slightly different from the semantics of comma-separated lists in properties (a single, comma-separated value), except when they _aren't_ (e.g. [modern color syntax](https://www.w3.org/TR/css-color-4/#color-syntax-modern)). Space-separated lists _tend_ to be reserved for shorthand values, except when they _aren't_ (e.g. [modern color syntax](https://www.w3.org/TR/css-color-4/#color-syntax-modern)).

Case in point, the [modern color module spec](https://www.w3.org/TR/css-color-4/) provides no explanation that I can see for why the syntax changed, what the motivation is/was, or, most importantly, what CSS currently considers to be an "argument" for a "function", or what it considers to be a list.

The reason I bring this up is that mixins / functions are ultimately built upon this CSS list ambiguity—CSS has no clear syntactic definition of a list, or when to use one list "type" over another. With defined functions, that's sort of alright, because CSS is full of micro-syntaxes, each function can essentially define it's own syntax. But with custom mixins and functions, you're suddenly painted into a corner. There is no "intuitive" way to define mixins / functions in CSS that is going to make sense to all developers, because CSS has no "generic" function argument list rules.

So, IMO, I feel like this is missing a very fundamental piece of discussion, which is to clarify, in CSS specs, what the list types are and what their intended use cases are. If the modern color syntax follows a new syntactic theory of lists, what is it? Why are some "arguments" separated by spaces, and some by slashes? (By the way, it's not just about those color functions -- there are other CSS function and list inconsistencies; its just the easiest go-to example.)

If CSS is going to essentially expand itself as having programmatic constructs, then I strongly believe it needs to more clearly define its syntax, specifically around lists. Without it, I don't believe the `@function` feature makes much sense; it imports an allegorical idea that can't be built on the same foundation. Mixins make some sense (if they don't take arguments)—having chunks of styles referenced in other styles is conceptually simple—but anything with arguments I think needs to supply this underlying work. Just because it exists in Sass, and to some degree, exists in Less, doesn't mean its built on foundational principles.

At the very least, I think CSS would best be served by chunking this work into these parts:
1. **CSS Mixins Level 1** - Implement (argument-less) mixin syntax.
2. Discuss and define CSS list syntax. Figure out all the historical "intuitions" about lists but redefine them with a set of rules to be applied moving forward for any new specs.
3. **CSS Mixins Level 2** - Decide on and possibly implement arguments for mixins.
4. **CSS Mixins Level 3** - Decide on and possibly implement argument "spread" syntax (should be back-ported to a new draft of the "list" spec), where that be with "..." or parens or braces or what have you.
5. **CSS Mixins Level 4** - Decide on if "functions" make sense, and if so, add to mixin syntax / spec.

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


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

Received on Wednesday, 13 November 2024 19:59:26 UTC