[csswg-drafts] [css-mixins-1] Problems with public representations of CSSOM values (#11908)

cdoublev has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-mixins-1] Problems with public representations of CSSOM values ==
They are minors so I hope it is okay if I do not create separate issues.

---

[`CSSFunctionRule.name`](https://drafts.csswg.org/css-mixins-1/#dom-cssfunctionrule-name):

  > **`name`, of type CSSOMString, readonly**
  >
  > The name of the custom function.

Shouldn'it be [serialized as an identifier](https://drafts.csswg.org/cssom-1/#serialize-an-identifier)?

`--cust\\ om()` [becomes](https://drafts.csswg.org/css-syntax-3/#consume-ident-like-token) `<function-token>` whose value is `cust om`, and `<)-token>`. Then these tokens [become](https://drafts.csswg.org/css-syntax-3/#consume-function) a function whose `name` is `cust om`.

The same question applies to [`FunctionParameter.name`](https://drafts.csswg.org/css-mixins-1/#dom-functionparameter-name).

---

[`CSSFunctionRule.returnType`](https://drafts.csswg.org/css-mixins-1/#dom-cssfunctionrule-returntype):

  > **`returnType`, of type CSSOMString, readonly**
  >
  > The return type of the custom function, represented as a [syntax string](https://drafts.css-houdini.org/css-properties-values-api-1/#syntax-string). If the custom function has no return type, returns `"type(*)"`.

`CSSFunctionRule.returnsType` may be internally represented as a `<type()>` (the result from parsing [`returns <css-type>`](https://drafts.csswg.org/css-mixins-1/#at-ruledef-function)) unless otherwise specified, and thus would not represent a valid syntax string.

So I would first suggest:

  > The return type of the custom function:
  >
  >   - if it is a `<syntax-component>`, represented as a syntax string
  >   - if it is a `<type()>`, represented as its value as a syntax string
  >   - if it is not defined, as `*`.

Now I do not see why it should be represented as a syntax string rather than the serialization of `<css-type>`. Is it intentional? Plugging it in `@property/syntax` (the only value defined with a syntax `<string>`) does not seem useful. I would have thought that representing a syntax as a `<string>` would become legacy.

The same problem/question applies to [`FunctionParameter.type`](https://drafts.csswg.org/css-mixins-1/#dom-functionparameter-type).

---

[Serialize a function parameter](https://drafts.csswg.org/css-mixins-1/#serialize-a-function-parameter):

  > 2. If the function parameter has a type, and that type is not the [universal syntax definition](https://drafts.css-houdini.org/css-properties-values-api-1/#universal-syntax-definition):

The universal syntax definitions is (implicitly) defined as the value `*`, which is not a valid function parameter type value.

This intent is unambiguous, of course, but this and the other points above make me wonder if the spec expects implementations to store syntaxes unwrapped from `type()`.

  > 3. If the function parameter has a default value:
  >
  >    A single COLON (U+003A), followed by a single SPACE (U+0020), followed by the result of performing [serialize a CSS value](https://drafts.csswg.org/cssom-1/#serialize-a-css-value) on that value.

*Serialize a CSS value* is intended for declarations whereas [`<function-parameter>` ](https://drafts.csswg.org/css-mixins-1/#typedef-function-parameter)may look like a declaration but its value is optional and it may also have a type. Should it be [serialize a CSS component value](https://drafts.csswg.org/cssom-1/#serialize-a-css-component-value) instead?

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11908 using your GitHub account


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

Received on Tuesday, 11 March 2025 15:19:43 UTC