[css-properties-values-api] `@property` descriptors should be optional whenever possible

[Crissov]

@property rules require a syntax and inherits descriptor;
if either are missing, the entire rule is invalid and must be ignored.

This requirement seems very unlike any other declaration list in CSS.

@property --partial { }
@property --partial { syntax: "*"; }
@property --partial { syntax: "<length>"; }
@property --partial { inherits: true; }

should be equivalent to

@property --partial {
  syntax: "<length>";
  inherits: true;
}

The initial-value descriptor is optional only if the syntax is the universal syntax definition,
otherwise the descriptor is required;
if it’s missing, the entire rule is invalid and must be ignored.

Particularly with multiple custom property names per #1058, which will frequently just differ in initial-value, these requirements combined would still lead to needless repetitions.

[LeaVerou]

For background the inherits descriptor was made mandatory because the obviously reasonable default value, is also more expensive so @tabatkins felt it should always be a conscious decision.
FWIW I agree that it should have been optional — it's an antipattern when transient performance considerations drive API design. But hey, at least we can always make it optional!

I also think we could have reasonable initial initial values (yes, I just did that 😅) for the initial-value descriptor instead of requiring it every time. 0px, transparent, image(transparent) etc.

And yes, syntax: "*" should just be the default.

[AtkinsSJ]

Perhaps the default values should match how an unregistered custom property behaves? Or at least as close as possible. initial-value is the only part that's tricky there I think as it would be the <guaranteed-invalid-value> which isn't representable, though it is already the default if it's not specified.

So these would be equivalent:

@property --a {};

@property --a {
	inherits: true;
	syntax: "*";
	/* initial-value: guaranteed-invalid-value; */
};

[SebastianZ]

@Crissov You're mixing two things here, which I think should be discussed separately:

1. Allowing to overwrite and extend an existing custom property definition. (Currently the last one wins.)
2. Making all descriptors optional.

So I suggest to open a separate issue to discuss point 1.

Regarding point 2, it also tripped me up many times that the inherits descriptor is not optional. So yes, I'm also for making them optional.

For background the inherits descriptor was made mandatory because the obviously reasonable default value, is also more expensive so @tabatkins felt it should always be a conscious decision.

What is the obvious reasonable default value? For me, it would be not to inherit, as most of the properties I define don't need to inherit. (And yes, that goes against how unregistered properties behave, so against what @AtkinsSJ wrote.) But I get the point that it would be more consistent to let them inherit by default.

Either way, I don't get the argument why that should be more expensive. If it's to inherit by default, then it's not different to declaring them via declarations, which is what authors usually do. And not inheriting by default sounds less expensive to me.
So maybe you or @tabatkins could provide some background here?

Sebastian

[LeaVerou]

@AtkinsSJ

Perhaps the default values should match how an unregistered custom property behaves? Or at least as close as possible.

Yup. That’s on par with the principle of least surprise: you declare the things that are different from the default behavior, rather than having a bunch of things change that you did not declare, requiring you to write extra code to go back to the default behavior.

initial-value is the only part that's tricky there I think as it would be the <guaranteed-invalid-value> which isn't representable, though it is already the default if it's not specified.

So these would be equivalent:

@Property --a {};

@Property --a {
inherits: true;
syntax: "";
/ initial-value: guaranteed-invalid-value; */
};

Ooh I really, really like this. Currently there is no way to register a custom property and still have fallbacks, which limits what you can do with it. This would solve that AND the ergonomics issue in one fell swoop.

---

@SebastianZ

What is the obvious reasonable default value? For me, it would be not to inherit, as most of the properties I define don't need to inherit. (And yes, that goes against how unregistered properties behave, so against what @AtkinsSJ wrote.) But I get the point that it would be more consistent to let them inherit by default.

See above.

Also I would question how universal this is:

For me, it would be not to inherit, as most of the properties I define don't need to inherit.

This has not been my experience, at all. Most of the properties I define do need to inherit.

Either way, I don't get the argument why that should be more expensive. If it's to inherit by default, then it's not different to declaring them via declarations, which is what authors usually do. And not inheriting by default sounds less expensive to me. So maybe you or @tabatkins could provide some background here?

IIRC inheriting was more expensive. I agree it's no different to declaring them via declarations. Perhaps @tabatkins can clarify.

[Crissov]

My reason for combining both topics in one issue is that I’d be fine with requiring some or all descriptors to be set explicitly for the final registration of a custom property to take effect, but I believe that in each individual ruleset every declaration should be optional. It follows naturally that later definitions only overwrite the values of descriptors they set explicitly.