[css-properties-values-api] Shorthand for custom property declaration

[korenevskiy]

Let's create an abbreviated form of writing properties and variables.

When there are variables in the amount of 1000 pieces, then this is a heavy code.
It was:

@property --color {
  syntax: '<color>';
  initial-value: red;
  inherits: false;
}

Will be:
It would be convenient to have an abbreviated spelling :

@--gradient-start: <syntax> <initial-value> inherits;

Example:

@--gradient-start: color red inherit;

In the writing of 2 dashes they will show that this is a property.

@--header-color: color white noinherit;
@--header-background-color: color black noinherit;
@--header-border-color: color green noinherit;

@--wiget-color: color white noinherit;
@--wiget-background-color: color black noinherit;
@--wiget-border-color: color green noinherit;
....
....
And so on and so forth

<aside style="@--title-color: color white noinherit;">... html code</aside>

Use default values for each type:

color default: black;
font size default: 1 rem;
lenght size: 1px;

Short write propertis without default value:

@--header-color: color;
@--header-background-color: color;
@--header-border-color: color;

@--wiget-color: color;
@--wiget-background-color: color;
@--wiget-border-color: color;
....

[chriskirknielsen]

Cool idea! I do agree that it can clutter up a file to declare many properties, and that some shorthand could be beneficial.

Not sure about the syntax as it can look a little unclear (my first thought was "custom media query" but that's not the syntax), however I could see something like:

@property --header-color: '<color>', blue;
@property --corner-radius: '<length-percentage>';

(where lengths have an implicit default of 0 (with a unit where relevant), colours implicitly have black, and so on — and inherits defaults to true)

It stays compact while still being an explicit "hey I'm defining --prop" and uses the same syntax. (syntax would have to always be first in case you had a custom ident that looked like a syntax data type)

Might even be able to follow the @layer approach and list several in one go, but parsing might get tricky:

@property --header-color, --header-background-color, --header-border-color: '<color>';

[korenevskiy]

For color format write, please write as this code. @chriskirknielsen

@property --header-color: '<color>', blue;
@property --corner-radius: '<length-percentage>';

[SebastianZ]

Somewhat related regarding multiple declarations: w3c/css-houdini-drafts#1058

I strongly agree with @chriskirknielsen that if such a shorthand is introduced, it still needs to be based on the @property rule. Without that info it is unclear what's defined by that rule.

Regarding the rest of the syntax, I think the colon isn't necessary. Though there's an issue with the comma used to separate the descriptors or multiple property declarations because that's already allowed in the initial value syntax. Generally speaking, any tokens that can be part of a <declaration-value> are allowed.
So, either a separator not allowed in <declaration-value> would need to be used or the shorthand would have to be restricted to @property <custom-property-name> <custom-property-syntax> <custom-property-initial-value>;.

Sebastian

[chriskirknielsen]

If the colon is a problem, perhaps a keyword like as?

@property --foo, --bar as '<integer>';

You'd then still be able to have commas on either side to identify a list of property names vs values. I am however not familiar with parsing rules so maybe it just introduces another issue.

Lea's proposal with the wildcard is also a nice way to do it if you follow a convention like --color-*.

[korenevskiy]

We have several possible syntax options.
But now let's discuss how such a syntax should be displayed in the browser developer panel.
Suppose :

<div style='@property --foo, --bar as color'>

or

<div style='@property --foo, --bar : color'>

In the browser, we select this element in the developer panel. How this style should be displayed below in styles?
Indeed, in styles the panel has 2 columns.
Property name and near property value.

Sorry that the tex is crossed out, 2 ways to display the style.

There is another suggestion.

It would be convenient for us to be able to write as additional as ?

aside.banner,
div.breadcrambs{
	@property: --foo, --bar as color;
	color: var(--foo);
	background-color: var(--bar);
}

I offer this option not as a replacement, but as a complete with new opportunities.
AND
JavaScript

document.querySelector('.banner').property = "--foo, --bar as color;"
// OR
document.querySelector('.banner').propertis.foo = "color;"
document.querySelector('.banner').propertis.bar = "color;"

We must look to the future in case of JS support
PS I suggest that "AS" suffix not write.
AND
I propose commas to simplify (delete) as well.

aside.banner,
div.breadcrambs{
	@property: --foo color, --bar color;
}

<div property='--foo color, --bar color'>

Let's dwell on a simple option without commas and without the AS suffix .

This will allow you to scale this property.

HTML has a DATA-*="" attribute
The task of this attribute is to separate user variables from browser variables. This syntax is for HTML code.
It turns out that CSS variables also need to be separated from browser variables, for this you can use the property attribute in HTML code.

[korenevskiy]

And what prevents in styles from using the word PROPERY?
In my first sentence

@--foo: color;
@--bar: color;

dovy dashes are written. The presence of double dashes will show that this is a property that will not be a problem in the future for media expressions
This will reduce the code, it will not conflict with anything at all.
After a year of use, such a short form of writing will not cause questions at all. It will usually be, and everyone understands the meaning.
But the site code will be less.
It is very similar

 --foo: brown;
 --bar: brown;

 div.breadcrambs{
	@--foo: color brown;
	--bar: red;
}

Very similar
Or maybe not to use media expression at all?
We will simply expand the CSS type variables

 div.breadcrambs{
	--foo: brown color ;
	--bar: red color ;
	--big: initial color ;
	--ben: initial color ;
}

[korenevskiy]

@chriskirknielsen @SebastianZ @jonleighton @hober

What do you think of syntax without dogs at all?

 div.breadcrambs{
	--foo: brown color ;
	--bar: red color ;
	--big: initial color ;
	--ben: initial color ;
}

[chriskirknielsen]

I am not privy to the parsing but it seems you want to declare scoped custom properties, per selector, and I am not sure that's possible with the @property rule. Maybe some new stuff in the spec regarding container queries or scoping would enable this but I honestly do not know.

Additionally, in your proposed form, the browser has no way to know the difference between a custom property value and custom property registration, since --foo: color brown; is a totally valid custom property value in itself.

That is also a bit different from your initial proposal in some ways so I am not sure it's viable in its latest form, but still believe the one-line syntax @property --foo... could be exploited (@property --foo, --bar as '<syntax>' initialValue would be my preferred approach but that's another discussion).

[korenevskiy]

@chriskirknielsen I did not know that such a syntax is acceptable.
I just checked, it is also permissible to use commas in variables.
I also like to use the word @Property. But I want to offer a syntax so that at the moment it is simple, and in the future the syntax has the opportunity to expand the funzkional.
If my short synstaxis is a failure, I would gladly agree to your offer.
But I ask you for help, and help you come up with an indication of the type in a simple syntax for specifying values.

 div.breadcrambs{
	--foo: brown ;
	--bar: red ;
}

Help you create idea out how to insert typization into this format.

[bramus]

I strongly agree with @chriskirknielsen that if such a shorthand is introduced, it still needs to be based on the @property rule. Without that info it is unclear what's defined by that rule.

+1

So, either a separator not allowed in <declaration-value> would need to be used or the shorthand would have to be restricted to @property <custom-property-name> <custom-property-syntax> <custom-property-initial-value>;.

What about @property <custom-property-name>+ <custom-property-syntax> <custom-property-initial-value>;? That would allow definition of multiple custom properties in one go

@property --min --max --avg number 0;

[tabatkins]

I don't want to shove the existing descriptors into an unlabeled prelude space; that's hostile to future expansion, as we'd have to make sure the descriptor syntaxes either work together, or have an alternate form when in the prelude.

However, generally the repetitive part comes from repeating the @property keyword itself, and the syntax/inherits descriptors. Initial values are either distinct per property, or at least short enough that it's fine to repeat.

So, since custom properties are grammatically distinct from normal descriptors, we can do the defaults and the name/initial pairs together, like so:

@properties {
  syntax: "<color>";
  inherits: false;
  --brand-color: teal;
  --text-color: black;
  --bg-color: white;
  /* more names and initial values here */
}

Hm, this isn't even more verbose than the current @property for a single variable. Dang, we probably could have just used it in the first place. I guess it does require setting an initial value, tho, which @property lets you forgo if you're using "*" syntax, but that's a pretty minor thing (and we could avoid it by saying initial as the value). It's probably too late for that tho, huh.

[andruud]

Just brainstorming:

@properties

@layer (non-plural form) allows specifying multiple layers, so we could re-use @property (non-plural) to specify multiple properties.

Initial values are either distinct per property, or at least short enough that it's fine to repeat.

Maybe we can allow env(--my-thing) in these values for the cases where repeats are annoying (see #9206).

And/or allow the initial-value descriptor:

@property {
  syntax: "<length>";
  inherits: false;
  initial-value: 2147483647px;
  --width: initial; /* 2147483647px */
  --height: initial; /* 2147483647px */
  --depth: 0px;
}

Then we could say that the old form @property --x { syntax: "<length>"; inherits: false; initial-value: 0px; } is equivalent to @property { syntax: "<length>"; inherits: false; initial-value: 0px; --x: initial; }.

[mirisuzanne]

This syntax works well for grouping multiple property definitions that share features, but I think it's missing some attention to larger issues in how authors and browsers think about property registration and definitions. I would really like to see a more comprehensive plan for author-ergonomic 'design token' management.

In my experience, authors currently use the :root and * universal selectors to define most custom properties, and only add formal @property registration when they explicitly need a syntax for the purpose of interpolation. However, with a shorthand like this, authors might expect that they are doing both in one place: registering an initial value, and also establishing a root/global value. That would be excellent if they could, but currently there's a big technical difference.

Initial values are required to be 'computationally independent' when there is a defined syntax - which means the initial value cannot reference other custom properties, or even use relative units. I don't know what leads to that limitation from an implementation perspective, but it doesn't match author expectations for defining custom properties, and won't work for most use-cases. As long as that restriction is in place, authors will need to keep defining a majority of custom properties on root/global selectors, even after they have a shorthand for registering syntax and initial values – meaning most properties will still need to be defined in two places.

In some ways, this is the distinction we also have between spec-defined 'initial' values, and browser-defined 'default' values – which are defined in distinct places, for distinct reasons. And for some author-origin use-cases that will make sense. A shared design system or framework can register properties with computationally independent 'initial' values, and the consuming stylesheets can apply selector-based 'default' values. But in many cases, authors have no reason to distinguish between the two. Most authors don't even know that the distinction exists in CSS. For the majority of design-token use-cases, authors will want initial and default values to match – and in many of those cases, variable-reference and responsive units are essential.

I don't know if it's possible to remove the limitation from initial values? But if not, it would be nice to have a way of setting root/global default values in the same place where registration happens. I think this will also be essential for #2627, since authors will expect to have responsive units in global environment variables.

(Root vs global selectors are used by authors as a shorthand for toggling inheritance without formal registration)

[Loirooriol]

How would em even behave in such a global context? The only reasonable answer seems against the initial value of font-size, just like rem on the root element's font-size. Is this what authors want?

[mirisuzanne]

@Loirooriol the behavior of em is already well-defined in all the contexts where authors will are allowed to use them – even in global contexts like media queries. And authors often use then in media queries with that limitation. So yes, in media queries it would be resolved to the initial value of font-size. In container queries, it would resolve to the container font size. Etc.

From the author perspective at least, we don't need a universal answer outside the contexts where length values are allowed. 2em is a valid length, and should be allowed as an initial value, even if it will have different meanings in different contexts. Context-dependence is the whole point of the responsive unit.

But more to the point, and as Tab has mentioned elsewhere: authors won't always want to distinguish in advance between global-only constants and element-only variables. Ideally, we'd want to define a name and initial value (available globally or locally), and then also have the option to override that value on specific elements in the cascade. The distinction could instead be made in how we access those values: using e.g. env() to return the globally-constant initial value, and var() to access the cascade-dependent value. Both of those should be able to return a <length> in em units, and then resolve the units where they are valid, with whatever meaning em units have in that situation.

[andruud]

From the author perspective at least, we don't need a universal answer outside the contexts where length values are allowed. 2em is a valid length, and should be allowed as an initial value, even if it will have different meanings in different contexts. Context-dependence is the whole point of the responsive unit.

I'll say it again since we're discussing the same thing in multiple issues: this idea is not compatible with the other goal (stated here or a related issue) of making "global" custom properties even more global for performance/memory reasons. In fact it makes it much worse. Currently, if the computed value of a custom property is the initial value, we can represent that (per-element) as not storing it on the element, and instead looking up the (per-document) initial value. With this new idea, we'd actually have to add the initial value(s) to the cascade for each element, duplicating the whole set of custom properties for each element (in the worst case).

But "unfortunately" it makes a lot of sense from an author perspective, and together with the env(--mything) approach it seems to solve everything ...

[tabatkins]

Quick aside about the "computationally independent" - the reason for that restriction is to avoid authors having to think about what lengths like 3em are resolved against, and how the behavior is different based on your syntax. An initial value of 3em with a syntax of "*" means the value isn't resolved until it's used on an element so it'll be font-size specific, but a syntax of "<length>" means we'd resolve it to a specific length and it wouldn't respond to each value. By disallowing such values entirely we avoid the potential confusion. (For "computationally independent" values, the behavior is the same regardless of syntax.) However, we definitely could allow them and resolve them against the global value, if we're okay with this. (Or condition to only be allowed for "global only" variables, where there's no confusion potential.)

---

And yeah, I think being able to address the "performance" issue is pretty important, so we do need a way to declare that a custom property will not be changeable per-element, so we can avoid tracking the property in per-element data structures entirely. My objection was to forcing authors to switch their definition and referencing syntax based on whether it's global or not; ideally we can keep these close.

So, proposal:

• When you register a property, you can declare that it's immutable or global or whatever. This (a) removes the "computationally independent" restriction, resolving them against global values exactly like they are in MQs/etc, and (b) makes the variables no longer changeable on individual elements.
• You can still use var() to refer to "global" variables, as normal. (We'd just look for the name in the global table first, then on the element's properties. Various optimizations are possible here, like the globals exposing a bloom filter or something.)
• You can also use env() to refer to "global" variables. On an element this is just for clarity, to explicitly indicate you're using a global value rather than an element-specific variable. But env() is allowed in various global contexts, like MQs, where var() isn't.
• Maybe you can use env() to refer to the initial value of non-global properties, too. This is kinda a nice-to-have, I don't think there's a use-case driving this right now. But it would give us a nice consistent behavior, where var()-vs-env() is independent from global-vs-mutable (it's just that global+var() is identical to global+env()).

We'll need to carefully define cycle handling in global variables, of course. Assuming we want @Property registrations to be changeable based on MQs (for swapping colors based on color-scheme, for example), we'll need to add some dependency edges based on use in MQs you're nested in. I don't think this is very hard, but it's definitely new code to determine and track these dependencies. (Alternatively, we don't allow them to be nested, and instead rely on solving this in the property-value space; see recent discussions on light-dark() function that responds to per-element color-scheme, and similar discussions about a media() function usable in var-like contexts. So you'd just set your initial value to be media-dependent or whatever using that stuff. But that means we need to also do @supports/etc.)

[tabatkins]

@layer (non-plural form) allows specifying multiple layers, so we could re-use @Property (non-plural) to specify multiple properties.

Hm, we do expose the two types of @layer as two different OM rules, based on which syntax you're using. I suppose that would be okay; the existing @property syntax continues be a CSSPropertyRule, while the multi-registration version is a CSSSeveralPropertiesRule or whatever.

[andruud]

However, we definitely could allow them and resolve them against the global value

This (a) removes the "computationally independent" restriction, resolving them against global values exactly like they are in MQs/etc

@tabatkins "Global" you say, but what do you think about @mirisuzanne "real" ask here, which is that initial values of registered custom properties can exist in an unabsolutized (but typed) form? To be specific:

@property --x {
  syntax: "<length>";
  inherits: false;
  initial-value: 10em;
}
/* --x is a <length>, can interpolate as <length>, has a type in computedStyleMap(), etc. */

#div1 { font-size: 10px; } /* => gCS(div1)['--x'] => 100px */
#div2 { font-size: 20px; } /* => gCS(div2)['--x'] => 200px */

[tabatkins]

The problem is that ems (and similar) have rules for when they evaluate - you'll never see an em in a property you've inherited, in any property, custom or not. This ties into the similar request for a way to delay substitution of a var() until somewhere later, rather than immediately at computed value time on the element it's first defined, and should probably be addressed in the same way, with some sort of "defer evaluation" behavior where you can trigger evaluation later (or have it happen automatically when subbed into a non-custom property).

So that's a separate issue. ^_^

[MrHBS]

It's probably too late for that tho

FWIW @property isn’t supported by Firefox ( it is available in nightly build though ). I don’t know if this is enough for a reason to do a breaking change here.

[korenevskiy]

It's probably too late for that tho

FWIW @property isn’t supported by Firefox ( it is available in nightly build though ). I don’t know if this enough for a reason to do a breaking change here.

The CSS language should be simple. And the syntax of the new properties and styles should be intuitive. A person should not memorize the syntax of a single property. This is a mockery of a person. Life is complicated enough as it is.

[brandonmcconnell]

The CSS language should be simple. And the syntax of the new properties and styles should be intuitive. A person should not memorize the syntax of a single property. This is a mockery of a person. Life is complicated enough as it is.

Shorthand properties/syntaxes like the one proposed here are not simple and often add unnecessary complexity to the language.

One clear case of this is the background shorthand which many CSS devs, myself included, still don't get right on their first try after a while of not using it.

Shorthands may look simple, but the DX surrounding shorthand is not great.

Some shorthands like border may be considered an exception to that rule, but especially for defining the parameters of a custom property in the way that @property does, it would be very hard. The @property is still being actively developed, discussed, and added to. If we add several more properties to the @property, the shorthand syntax would be near impossible to maintain.

@--variable name: <syntax> <initial-value> <inherits> <access-level> <global-scoping> <...>;

[korenevskiy]

You're right, but that doesn't mean it's a bad idea. It's a good idea. I just need to optimize my offer.
It may be necessary to exclude the default value in an abbreviated form.

@property --color {
  syntax: '<color>';
  initial-value: red;
  inherits: false;
}

we have 5 lines

But the same thing can be written like this

@--color: <syntax>;
--color: <initial-value>;

We just define the value in the usual way. But we also know that redefining a variable deep down is inherited. Which does not break compatibility.

[brandonmcconnell]

@korenevskiy You're right. It's not a bad idea, and your new suggested approach is already much better in my opinion.

If we assume that in most "simple" situations, the @property rule only uses those values, we could even set it up to use those three and no others, like this:

@--name: '<syntax>' inherits / initial-value;

Using the slash delimiter here is valuable to distinguish between the initial-value and inherits values. A syntax type of '<boolean>' is in the works (though still years out), so it could be confusing to eventually have multiple neighboring booleans inline:

/* not great ❌ */
@--active: '<boolean>' true false;

/* better ✅ */
@--active: '<boolean>' true / false;

/* is equivalent to: */
@property --active {
  syntax: '<boolean>';
  inherits: true;
  initial-value: false;
}

This also has the added benefit of allowing exclusion of the inherits value when true if desired, as it defaults to true. So the above line can be simplified further:

@--active: '<boolean>' / false;

/* is equivalent to: */
@property --active {
  syntax: '<boolean>';
  inherits: true;
  initial-value: false;
}

Removing the slash changes the meaning of the boolean value—in this case—to be the inherits value rather than the initial-value:

@--active: '<boolean>' false;

/* is equivalent to: */
@property --active {
  syntax: '<boolean>';
  inherits: false;
}

[korenevskiy]

I made a big mistake, CSS should not turn into a programming language. and also the properties themselves should mean what they say. I.e. I want to say that you can't write TRUE and FALSE to denote inheritance, you have to write the word inheritance and not inheritance. Perhaps this will allow you to mix values without a slash. There are a lot of such properties in other styles. for example, a border or font or background.

@--color: 'color' inherit red;

or

@--color: 'color' red inherit;

[korenevskiy]

@--font: 'font-famaly' inherit 'Arial';

or

@--font: 'font-famaly' 'Arial' inherit;

And it is also desirable that you do not have to put quotation marks.
for simple values without delimiters, it was possible without the quotes.

@--color: color red unherit; 

[brandonmcconnell]

I agree that avoiding a boolean value for inherits would be best, though the use of inherit in your recent example suggests that without it, it would not inherit, which inverts the default inherits value from @property so that probably wouldn't work either, as it would be very confusing to users to have opposite default values between the @property and @-- syntaxes.

Maybe we do introduce a different keyword for that though, like no-inherit.

[korenevskiy]

I just don't know English well, I write through a translator. But, I wanted to convey the meaning. Thanks for the clarification.

But the keyword "no-inherit" should be without a hyphen to make it easier to write. And maybe it will be a little easier for the parser.
noinherit

[korenevskiy]

@brandonmcconnell Thank you for your participation, we would not have improved the new typing format.

[brandonmcconnell]

Yes, I considered a non-hyphenated noinherit version as well.

Weighing the readability of no-inherit against the ease of writing noinherit— either is fine, and I don't think the parser would have an issue with either.

[korenevskiy]

I agree that they will not arise. I also considered readability. Brevity won out in my head. I'm worried that it's very stressful to hit a hyphen with your finger while typing. Perhaps enterprising craftsmen will print like this:
noInherit

[korenevskiy]

Or maybe you can see the first letters of NO , the master will understand what is written next Inherit

[brandonmcconnell]

A case-insensitive noinherit could work well, similar to the treatment of currentcolor

[korenevskiy]

and what is more correct: noherit or noinherit?

[korenevskiy]

do I need me to put our new ideas with you in the main description at the top of the PR?

[Loirooriol]

noinherit is an antipattern. nowrap and currentcolor were mistakes.

I'm not even sure what unherit or noherit are supposed to mean.

Not having proper separation between the initial value and other parameters seems like a huge mistake.

[korenevskiy]

Do you mean the slash?
Do you evaluate this from the point of view of the parser, or from the point of view of readability or writing?
Perhaps the default value should not be specified in the typing at all. just type and inheritance. And we specify the value below as a regular variable.

@--color: color inherit;
--color: red;

[korenevskiy]

Delimiters, as well as hyphens, create stress on the brain. We just remember the general syntax of all CSS properties, but then it turns out that some of them are written with a comma, some with a slash, some with a space. it is necessary to study each case separately, for those who do not print every day or those who remember but do not use, you have to look for reference books to remember the format of the string.

[brandonmcconnell]

@Loirooriol What are your thoughts then on an approach to inherits, since the @property already inherits by default. We would essentially need a way to prescribe in the shorthand syntax to "not inherit" since the default is false, same as using inherits: false in the verbose @property syntax.

Could you provide feedback on this message specifically?:
#7523 (comment)

@--name: '<syntax>' inherits / initial-value;

@--my-color: '<color>' blue;

Maybe we just assume that if you use the shorthand, you are opting into inherits: true. If you want to set inherits: false, use the long-form (@property).

[korenevskiy]

I completely agree, the default value must be. I just thought that other than that we were discussing the meaning for explicit indication.

I still don't understand why the value of the grid-template-areas property is written in quotation marks. It is quite logical that there should be no quotation marks here, it is enough just to separate groups of positions with commas. Here, too, it is necessary to keep a special case in mind, we should not create special cases of separators.

[korenevskiy]

why do you write angle brackets around the color?

My Option.

@--my-color: color;

@--my-color: color blue;

@--my-color: color inherit;

@--my-color: color inherit blue;

[Loirooriol]

@korenevskiy I'm evaluating this from the point of view of the language, not just the parser. I will probably object against things that might seem to improve readability/writing if they don't mix well into the language.

How do you represent that in CSSOM? What happens if --color: red; is missing after @--color: color inherit;?

@brandonmcconnell My thoughts are that, if we add some kind of shortcut to register custom properties, it should probably be along these lines: #7523 (comment)

Using / as a separator can also be problematic if you want to define an initial value that contains /, e.g. because you plan to use it in grid-area.

[korenevskiy]

Well, writing without the default value will be bad, but then let's think about the errors. How the browser will behave when it reads an error variable without specifying the default color. This is an obvious mistake, but it was written by the developer. What should the browser do then?

@Loirooriol I also rate in terms of readability and writing. but I may not know the concept of the language well. Moreover, I did not offer anything that violates readability and writing.

[korenevskiy]

I suggest the default color value is transparent.
and also for the length it is 0

---

moreover, the short form of types should be short, maybe the master does not need inheritance, he needs to define the color in the configuration. If he wants, let him redefine the color values or not define them in variables.
The short form of the types should be mandatory only for the type of the variable.

---

The font-family type will have the default value that the browser has for the font.

---

otherwise, it turns out that the font is not loaded, and the base font of the browser does not match the one that is set by default for the font type.

---

The browser also has its own default values for each type. Anyway. There are always default property values that have their own default values.

[MrHBS]

I think we have a very solid proposal from @andruud. Can this issue be discussed at the next meeting?