Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-properties-values-api] initial-value for * with arbitrary substitution values #1120

Open
cdoublev opened this issue Jan 29, 2024 · 4 comments

Comments

@cdoublev
Copy link
Contributor

If I understand the spec correctly, initial-value does not require to be validated when syntax is *.

But in Chrome, given the CSS rules below:

  • the first rule is valid: initial-value: var(1) is discarded
  • the second rule is invalid
@property --p1 {
  inherits: false;
  syntax: "*";
  initial-value: green;
  initial-value: var(1);
}
@property --p2 {
  inherits: false;
  syntax: "*";
  initial-value: green;
  initial-value: var(--initial);
}

I am completely confused by the parse result in Chrome. Anyway, should initial-value be invalid when it includes an arbitrary substitution value?

@tabatkins
Copy link
Member

Hm, the spec is indeed unclear here. I prefer Chrome's behavior - validating the initial-value as normal for an untyped custom property. The spec just needs its conditions to be slightly rephrased to match.

@cdoublev
Copy link
Contributor Author

cdoublev commented Oct 3, 2024

To clarify my understanding:

  • in the first rule, initial-value: var(1) makes the descriptor invalid and ignored
  • in the second rule, initial-value: var(--initial) makes the rule invalid because it is computationally dependent

That is, var(1) is invalid at the syntax level of initial-value, as specified:

If a property contains one or more var() functions, and those functions are syntactically valid, the entire property’s grammar must be assumed to be valid at parse time.

And initial-value: var(--initial) is invalid at the context level of @property, as specified:

  • The initial-value must be computationally independent.

If the above conditions are not met, the @property rule is invalid.

Computationally dependent values could have been specified as invalid at the context level of initial-value, but this does not seem important since authors will probably not make multiple declarations of initial-value.

So the specifications are already clear and I am closing this issue. I hope I am not missing something.

@cdoublev cdoublev closed this as not planned Won't fix, can't repro, duplicate, stale Oct 3, 2024
@cdoublev
Copy link
Contributor Author

cdoublev commented Oct 3, 2024

Indeed, I missed something. initial-value must be computationally independent only when syntax is *.

@cdoublev
Copy link
Contributor Author

cdoublev commented Oct 8, 2024

initial-value is technically a descriptor so var() parsing should not be triggered as it is only for properties, and initial-value: var(1) should be valid since var(1) matches <declaration-value>. This should also apply in CSS.registerProperty() (WPT), unless:

  • initial-value should be parsed as a property
  • var() (and other arbitrary substitutions) should always have a valid syntax, even when used in another context than a property value

This should then be explicitly specified in both cases.

But this is a different problem than a valid var(). Please let me know if I should open a separate issue.


There are these lines on WPT (it is about the first and the third):

// initial-value: not computationally independent
test_descriptor('initial-value', '3em', null, {'syntax': '"<length>"'});
test_descriptor('initial-value', 'var(--x)', null);

The spec requires initial-value to be computationally independent for @property to be valid, but only when syntax is not *.

An equivalent test exists for CSS.registerProperty(). So I guess there is a good reason.

I wonder which one it is, and whether it also applies to other substitution functions like attr() or first-valid().

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants