Well, "positive" is only allowed for integers, not numbers or dimensions, because it constitutes an open range otherwise, which is informally disallowed. We do use non-negative (sometimes paired with prose that floors it at some non-zero value), but that's harder to express easily.

Mathematically, "positive" usually means zero or greater, which is what I was thinking of, although depending on how the CSS parser handles -0, you might need some extra text in there.

"non-zero positive integer" would be another possible type, if that's actually required anywhere.

"non-zero positive integer" would be another possible type, if that's actually required anywhere.

It is: #341 (comment)

Mathematically, "positive" usually means zero or greater, which is what I was thinking of, although depending on how the CSS parser handles -0, you might need some extra text in there.

That's not really true in my experience? Zero is neither positive nor negative, and there's a lot of stuff backing that up: the relatively common usage of "non-negative" in precise technical contexts, the implementations of sign() functions in various languages, the fact that +0 and -0 are mathematically equivalent, etc. CSS has been pretty precise about this, because we've gotten bug reports about "why isn't 0 valid?" when we were imprecise and just used "positive". At best, whether 0 is considered "positive" or not is ambiguous and context-sensitive.

At best, whether 0 is considered "positive" or not is ambiguous and context-sensitive.

OK, I agree that a completely unambiguous terminology would be better. But the rest of my suggestion still stands: can we define <non-negative-integer>, <non-negative-length>, etc., data types, so that these restrictions do not have to be defined in prose?

I don't have a problem with this in theory, but in practice <non-negative-integer> eats up a much larger part of the measure. For grammars with more than a handful of possible value components, it triggers more wrapping and makes them harder to read. So while defining these limits in prose is maybe not ideal, I'm less than enthusiastic about adopting these new types. :(

We can go with shorter names; <p-integer>, <nn-integer>, etc. Unsure if that's worthwhile.

Yes, I'm certainly not stuck on the syntax. I just want the full parsing requirements to be unambiguously defined by the grammar.

Another approach would be to express it numerically, something like <length >= 0>, <integer > 0>, except without > characters! <length gte 0> and <integer gt 0>?

You could use more vulgar terms. They come with varying definitions outside CSS, but would of course have an unambiguous one inside:

• ℤ = <whole-number>, <integer>
• ℕ = <natural-number>, <natural-integer> – either positive or non-negative
• ℕ* = ℕ⁺ = ℕ₁ = ℤ⁺ = {1, 2, 3, …}: <ordinal>, <ordinal-number>, <ordinal-integer>, <rank-integer> … – positive
• ℕ⁰ = ℕ₀ = {0, 1, 2, …}: <cardinal>, <cardinal-number>, <cardinal-integer>, <size-integer>, <set-integer>, <counting-number>, <count-integer> … – non-negative

Thinking @AmeliaBR's latest idea further, <length min 0>, <length max 100% abs>, <integer 0..255> show different syntax that should be readable instantly for many people.

The discussion on clamping column width values (#1741) made me think of this again.

One final option for terminology: Take a cue from WebIDL, and use "unsigned" for values that cannot be negative. So it would be <unsigned-integer>, <unsigned-number>, <unsigned-length-percentage>, etc. For the rare cases: <non-zero-unsigned-integer>.

That said, I still think I prefer an explicit constraints syntax, like <length min 0>, as it is easier to understand on its own.

Regardless of the syntax, I still would very strongly like to add this option to the CSS grammar, so that all parser constraints on values can be expressed in the grammar.

So, I'm requesting this for the WG agenda, with the following questions for discussion:

• Should the CSS Value Definition Grammar be expanded to allow it to express all parser-level constraints on allowed values?

• If so, how should the constraints be expressed?

  1. By adding new data type names for all existing constrained types (non-negative numbers, non-negative lengths, strictly positive integers, etc.)?
  2. Or, by adding a generic way of indicating maximum and minimum values for any numeric type?

If we can get a resolution on those points, then we can bikeshed the exact syntax in a more focused way.

The Working Group just discussed Define <positive-integer>, <positive-number>, <positive-length>, etc. sub-types, and agreed to the following resolutions:

• RESOLVED: Extend value definition syntax to handle value ranges and possibly other syntactic restrictions, syntax TBD

FYI, I found a case of a numeric property defined to have a fixed range that isn't just non-negative or strictly positive. stroke-miterlimit was defined to accept a number (integer or decimal) that it must be equal to or greater than 1.

AKA <number --gte 1>, <number min=1>, <number [1,]> or however it ends up defined syntactically!

Of course, only one browser (Firefox) currently implements that exact rule as a parser-time check, see w3c/svgwg#545

Edit: as described in the linked issue, the property is now defined to accept any non-negative value.

I'd like to get a resolution on this at the February F2F.

Specifically, I'm advocating for the syntax that uses SGML-style attributes (<number min=1 max=10>). It's a familiar syntax for pretty much anyone who is working with CSS, it is explicit about the meaning, and it has the potential to be extended in the future.

For now, we would be adding min and max attributes to all numeric, length, and other quantity data types, including combinations such as <length-percentage>.

The min and max values would be inclusive. As Tab mentions earlier in the thread, we don't want open-ended bounds for non-integer values (e.g., to allow 0.00000000001 but not 0) because that gets into messy areas of numeric precision. For integer values, it is easy to just shift the minimum/maximum to the next allowed value (that is, to specify <integer min=1> instead of "integer greater than 0").

I haven't had a chance to do a comprehensive review of how many properties this would effect, but here are some examples from CSS Fonts Level 4:

• font-size

  <absolute-size> | <relative-size> | <length-percentage min=0>

• font-weight:

  [normal | bold | <number min=1 max=1000>]| bolder | lighter

• font-stretch:

  normal | <percentage min=0%> | <font-stretch-keyword-value>

• font-style

  normal | italic | oblique <angle min=-90deg max=90deg>?

As discussed previously, this syntax only covers parser-enforced restrictions on values, not clamping that happens at computed-value or used-value time. Specifically, any value that doesn't meet these constraints on the data type would make the surrounding declaration invalid, per CSS Syntax:

After each construct (declaration, style rule, at-rule) is parsed, the user agent checks it against its expected grammar. If it does not match the grammar, it’s invalid, and gets ignored by the UA, which treats it as if it wasn’t there at all.

Currently, the parser-level constraints on CSS values are defined by prose that states that certain values are invalid. E.g., the prose for font-weight currently says "Only values greater than or equal to 1, and less than or equal to 1000, are valid, and all other values are invalid."

The proposed change would encode those constraints directly in the CSS Values grammar.

I'd prefer to use mathematical range notation. It's a lot more compact, and part of keeping these grammars readable is keeping them compact enough to be visually parsed.

<angle [-90deg,90deg]>

Alternately some form of colloquial range notation (same rationale).

<integer 1+> <integer 0+> <percentage -100% to 100%> <percentage 0 to 100%>

(Maybe replace "to" with a proper n-dash. ;)

@fantasai Okay, so that's two additional syntaxes, for three alternatives so far.

So people can really compare, here's what they look like for the font properties I used in my comment above, along with my summary of pros and cons:

Attribute notation

• font-size: <absolute-size> | <relative-size> | <length-percentage min=0>

• font-weight: [normal | bold | <number min=1 max=1000>] | bolder | lighter

• font-stretch: normal | <percentage min=0%> | <font-stretch-keyword>

• font-style: normal | italic | oblique <angle min=-90deg max=90deg>?

Pros

• familiar syntax
• easy to read
• extensible to other types of constraints

Cons

• verbose

Bracket range notation

• font-size: <absolute-size> | <relative-size> | <length-percentage [0,]>

• font-weight: [normal | bold | <number [1,1000]>] | bolder | lighter

• font-stretch: normal | <percentage [0%,]> | <font-stretch-keyword>

• font-style: normal | italic | oblique <angle [-90deg, 90deg]>?

Pros

• compact
• uses a recognized syntax for people with a mathematical background
• similar to the syntax used for describing a number of repeated tokens

Cons

• similar to the syntax used for describing a number of repeated tokens
• the single-sided bounds syntax ([0,] for zero and up) may be confusing for those not familiar with mathematical range notation

Human-readable range notation

• font-size: <absolute-size> | <relative-size> | <length-percentage 0+>

• font-weight: [normal | bold | <number 1 to 1000>] | bolder | lighter

• font-stretch: normal | <percentage 0%+> | <font-stretch-keyword>

• font-style: normal | italic | oblique <angle -90deg to 90deg>?

Pro

• compact
• written the way you would read it

Cons

• The + notation can get lost among % signs or units.
• No syntax for a maximum bound without a minimum bound (but I don't think we have any use case for this).

(Maybe replace "to" with a proper n-dash. ;)

Nope. The whole idea is to make a grammar that is easier to auto-parse! Subtle typographic niceties not allowed! Especially because I want to eventually use the chosen syntax within author-supplied values to Houdini APIs.

• the single-sided bounds syntax ([0,] for zero and up) may be confusing for those not familiar with mathematical range notation

Would it be troublesome to do [0,∞]? We promised to keep CSS grammar ASCII-only, but not the description of its syntax. ^_^ (And I'm okay with an ∞ showing up in Houdini code.)

@tabatkins I thought about that as well. :) I say we go ahead and use it, but also accept the missing infinity version so that people who have trouble typing it don't have to.

Brackets and dots notation

An ellipsis made of three dots ... (not U+2026 …) could stand in for an infinity sign.

• font-size: <absolute-size> | <relative-size> | <length-percentage [0, ...]>
• font-weight: [ normal | bold | <number [1, 1000]> ] | bolder | lighter
• font-stretch: normal | <percentage [0%, ...]> | <font-stretch-keyword>
• font-style: normal | italic | oblique <angle [-90deg, 90deg]>?

Dots notation

This could be coupled with two dots to indicate a closed range, which in turn is just a variation of the human-readable range notation with .. substituting to and ... for +.

• font-size: <absolute-size> | <relative-size> | <length-percentage: 0 ...>
• font-weight: [ normal | bold | <number: 1 .. 1000> ] | bolder | lighter
• font-stretch: normal | <percentage: 0% ...> | <font-stretch-keyword>
• font-style: normal | italic | oblique <angle: -90deg .. 90deg>?

The CSS Working Group just discussed Adding min/max constraints, and agreed to the following:

• RESOLVED: We will use the bracket range notation

Bikeshed needs to be updated to work wit this, apparently

Bikeshed issue: speced/bikeshed#1441

I'll make the tracking issue for the edits once that is resolved.

Bikeshed's updated, plz make tracking issues @AmeliaBR ^_^

Darnit. I had such a good excuse for not working on this. Ok, I'll tackle that this weekend.

Ok, change of plans. I decided it's just as easy to make the edits as to make a few dozen issues. But I came up with a stylistic question:

Should I only be adding the bracket range notation to the blue-box definition, or also to prose references to syntax parts? I'm currently adding it in where there is a definition list that breaks out the syntax pieces, but am not otherwise adding it to prose.

I'm also leaving in all the prose restrictions (e.g. "negative values are invalid" or "negative values are not allowed").

Should I only be adding the bracket range notation to the blue-box definition, or also to prose references to syntax parts? I'm currently adding it in where there is a definition list that breaks out the syntax pieces, but am not otherwise adding it to prose.

I'm copying it to the dts defining individual grammar chunks; it's a relevant piece of information, and readers are well-served by surfacing it right at its actual point of definition.

I am removing prose restrictions that are entirely obviated by the grammar change, tho; we don't say in prose that a value "must be a length, or else it's invalid", etc., so when the grammar expresses that it's non-negative, no need to say that explicitly again in prose.