Feature request: Add unitless number properties data

[lifeiscontent]

Summary

It would be helpful to have a machine-readable list of CSS properties that accept unitless <number> or <integer> values (where units like px should not be added).

Use Case

CSS-in-JS libraries need to know which properties accept raw numbers without units. For example:

• opacity: 0.5 (unitless)
• z-index: 10 (unitless)
• flex-grow: 2 (unitless)
• line-height: 1.5 (unitless)

vs properties that need units:

• width: 100 → width: 100px
• margin: 10 → margin: 10px

Current State

The syntax field shows <number> or <integer> but doesn't clearly indicate whether the property is "unitless" in the sense that numeric values should NOT have units appended.

Proposed Enhancement

Add a unitless boolean field or similar indicator to properties that accept bare numbers:

{
  "name": "opacity",
  "syntax": "<alpha-value>",
  "unitless": true,
  ...
}

Or alternatively, a separate list of unitless properties.

Affected Properties

Common unitless properties include:

• opacity, fill-opacity, stroke-opacity, flood-opacity, stop-opacity
• z-index, order
• flex-grow, flex-shrink
• line-height (when unitless)
• font-weight (numeric values)
• orphans, widows
• column-count
• tab-size (when specifying character count)
• And more...

[tidoust]

I wonder whether we should make changes to the data for this one:

• I may have missed something but it seems to me that this can be fully determined by analyzing the existing syntax to detect occurrences of <integer> and <number>. For example, the syntax for opacity is <opacity-value>, whose syntax is <number> | <percentage>. That approach seems to work for all the properties you mentioned.
• Focus on unitless values seems specific to a particular usage. In the previous example, I would suspect that other tools would also want to know that the property accepts percentages as well.
• Some properties take multiple unitless values, or a combination of values with and without units. Functions may also take unitless values as parameters. That seems hard to capture with a single flag, and it seems hard to structure the data in a way that would be useful regardless of usage.
• We haven't tried to reproduce the units part of mdn/data to complete definitions of dimensions like <angle> and <length> so far. That could be done, and should be relatively straightforward as there aren't so many of them in practice (related comment in Group CSS features (and @webref/css v7 alpha release) #1519 (comment))

If there's logic that's common to multiple consumers and usages, it seems fine to upstream it in Webref. If the logic is somewhat specific to a particular usage and if the data already encodes the information somehow, it may be better to leave it to downstream projects. Now, parsing and making sense of the syntax is not necessarily straightforward. An alternative could also be to provide that logic through dedicated JS functions in the @webref/css package.

[stof]

@lifeiscontent the <number> and <integer> types are alwaysunitless.100pxis not a valid value for(it is a, which is a subtype of `)

[lifeiscontent]

Thanks @tidoust and @stof for the clarifications.

@stof - you're correct that <number> and <integer> are always unitless by CSS definition. My framing was wrong. What I actually need is the inverse: "which properties require units when given a numeric value?"

But as @tidoust points out, this can be derived by analyzing the existing syntax data. If a property's syntax (resolved through all type references) contains <number> or <integer>, it accepts unitless numbers. If it only accepts <length>, <time>, <angle>, etc., then units are required.

I think the right approach is:

1. Parse the existing syntax field to determine accepted value types
2. Build the "unitless" list downstream based on that analysis

@tidoust's suggestion of providing helper functions in @webref/css for common analyses like this is a good idea that would benefit multiple consumers.

This issue can probably be closed - the data is already there, just needs syntax parsing logic.