csswg-drafts icon indicating copy to clipboard operation
csswg-drafts copied to clipboard

[css-values] Range restrictions with units are unclear

Open Loirooriol opened this issue 2 years ago • 2 comments

https://andreubotella.com/csswg-auto-build/css-values-4/#numeric-ranges

<length [0,100px]> indicates a length between 0px and 100px (expressed in any unit).

The problem is that, while all lengths have compatible units that can be converted into the canonical px, this may not be possible at parse time. For example,

Name: foo
Value: <length [0,100px]>
Initial: ''0px''
div {
  foo: 1em;
  font-size: 50px;
}

Then foo: 1em becomes 50px which is within the range. But

div {
  foo: 1em;
  font-size: 200px;
}

then foo: 1em becomes 200px, outside the range.

So how is foo: 1em validated? Is it always allowed and then clamped at computed-value time?

It may just be simpler to say that range restrictions with dimensions require one side to be 0 (optionally with a unit) and the other side to be or -∞.

Loirooriol avatar Aug 09 '22 15:08 Loirooriol

It may just be simpler to say that range restrictions with dimensions require one side to be 0 (optionally with a unit) and the other side to be or -∞.

A percentage can also have a negative basis but I think the related productions do not use ranges.

I had become aware with the problem of validating non-absolute unit and applied the same strategy than for calculation: resolve a non-absolute unit when possible and validate it, otherwise the value is considered to be valid until computed value time. But I'm fine with reverting back to ranges with 0/∞/-∞ for dimensions/percentages.

EDIT:

I had a hard time understanding what I meant with my first sentence: similary as you concluded that lengths may have to define what happens for relative units, dimension-percentage mixed types may have to define what happens for percentages that can be resolved against a negative basis, or they should not use the range notation in this case.

For example, I would expect a negative <percentage> parsed against <length-percentage [0,∞]> to still be a valid input when it is resolved against a negative <length>.

cdoublev avatar Aug 09 '22 19:08 cdoublev

I was thinking about lengths, where values other than 0 and ∞ don't seem to make much sense.

But from #7571, font-style accepts oblique <angle [-90deg,90deg]>?, which seems useful.

So I guess this can be allowed when all units can be canonicalized at parse time, I think this is the case for all dimensions except lengths.

Lengths should either restrict the limits to 0 and ∞, or define what happens for units that can't be converted to the specified one at parse time.

Loirooriol avatar Aug 14 '22 19:08 Loirooriol

For numbers and units that are all canonically equivalent, any value makes sense. For lengths and similar, yeah, only 0 and the infinities really makes sense. That said, I don't think anything really needs to be changed in the spec, per se - we just need to not specify length ranges like that. (And it's possible that some contexts are fine to do it, like lengths in MQs where all allowed units are convertable at parse time.)

But we should indeed update the example to use <angle> instead of <length>.

tabatkins avatar Oct 10 '22 18:10 tabatkins

I'd prefer to explicitly forbid problematic cases, but fine

Loirooriol avatar Oct 10 '22 19:10 Loirooriol