Re: [csswg-drafts] [css-values] Define <positive-integer>, <positive-number>, <positive-length>, etc. sub-types (#355)

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](https://drafts.csswg.org/css-values/#numeric-types), [length](https://drafts.csswg.org/css-values/#lengths), and [other quantity](https://drafts.csswg.org/css-values/#other-units) 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](https://drafts.csswg.org/css-fonts-4/#font-size-prop)

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

- [font-weight](https://drafts.csswg.org/css-fonts-4/#font-weight-prop):

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

- [font-stretch](https://drafts.csswg.org/css-fonts-4/#font-stretch-prop):

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

- [font-style](https://drafts.csswg.org/css-fonts-4/#font-style-prop)

  `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](https://drafts.csswg.org/css-syntax-3/#css-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](https://drafts.csswg.org/css-values/#value-defs).

-- 
GitHub Notification of comment by AmeliaBR
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/355#issuecomment-458324757 using your GitHub account

Received on Monday, 28 January 2019 22:19:17 UTC