Skip to content

Apply the range definition notation #7400

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
33 tasks
cdoublev opened this issue Jun 22, 2022 · 4 comments · Fixed by #7407
Closed
33 tasks

Apply the range definition notation #7400

cdoublev opened this issue Jun 22, 2022 · 4 comments · Fixed by #7407

Comments

@cdoublev
Copy link
Collaborator

cdoublev commented Jun 22, 2022

I would like the range definition notation to be applied to value definitions whose interval is currently defined in prose. I can make pull request (a single or one per spec) if it helps to get this change sooner. The motivation is automatic parsing of value definition.

At least, the lists below can serve as a reference for the spec authors to update their definitions.

CSS property values

I excluded CSS 2 from my search.

Other CSS values

As noted in #7140, the range definition notation would need to be generalized in order to apply to a descriptor value or a value in a rule's prelude. I think it can be achieved with this change in CSS Syntax 3:

 Just like in property grammars, the notation `<foo>` refers to the "foo" grammar term, assumed to be defined elsewhere. Substituting the `<foo>` for its definition results in a semantically identical grammar.

+ For numeric data types, this type notation can annotate any range restrictions using the bracketed range notation described in [CSS Values](https://drafts.csswg.org/css-values-4/#numeric-ranges).

Multiple interval syntax

Some range definitions cannot be defined with the current notation because they have multiple intervals. It was not discussed in #355, where this notation comes from. I'm thinking of [x1,x2] [x3,x4] for this, which is similar but simpler than [x1,x2] ∪ [x3,x4] (union).

I thought there was a few more cases but I only found this one, so I guess I can live without this notation and implement a specific validation function for it.

  • [css-grid-1][css-grid-2] <grid-line>: auto | <custom-ident> | [<integer [-∞,-1] [1,∞]> && <custom-ident>?] | [span && [ <integer [1,∞]> || <custom-ident>]]
@dbaron
Copy link
Member

dbaron commented Jun 22, 2022

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

I think this requires units, i.e., <angle [-90deg,90deg]>

Likewise, I think these three require units since 0 is not a valid <time>, so they should be <time [0s,∞]>.

  • [css-images-4] <cf-image>: <percentage [0,100]>? && [<image> | <color>]

I think we should probably also use units for percentages, although I'm less confident of that. That is, <percentage [0%,100%]>.

Multiple interval syntax

  • [css-grid-1][css-grid-2] <grid-line>: auto | <custom-ident> | [<integer [-∞,-1] [1,∞]> && <custom-ident>?] | [span && [ <integer [1,∞]> || <custom-ident>]]

I think you could write [ <integer [-∞,-1]> | <integer [1,∞]> ] for this one case.

@tabatkins
Copy link
Member

+1 to all the feedback from dbaron.

I'm fine with this all being one big PR.

@cdoublev
Copy link
Collaborator Author

Below are all the existing ranges:

Production Ranges
<length-percentage> [0,∞]
<length> [0,∞]
<number> [0,∞], [1,∞], [0,1], [1,1000]
<integer> [0,∞], [1,∞], [0,10]
<percentage> [0,∞], [0,Infinity], [0,100]

It seems clearer to not omit the canonical unit. Unitless 0 for <length> and <angle> is more concise. It is forbidden in math functions but there are currently none that have a range constraint. ∞px or ∞% would be weird.

<length-percentage [0,∞]> looks problematic to me. CSS authors might think that unitless 0 for <percentage> is allowed.

The only alternative I see would be to define that the range applies to the numeric part of the component value, canonicalized in the case of a dimension.

I think that Infinity could be normalized to for consistency and conciseness.

@tabatkins
Copy link
Member

So long as it's clear, I think the range limitation is fine without units, yeah. 0 and infinity are always clear; numbers/integers are correct anyway, and percentage has a single possible unit so non-zero values are clear too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants