csswg-drafts
csswg-drafts copied to clipboard
[css-values] Range restrictions with units are unclear
https://andreubotella.com/csswg-auto-build/css-values-4/#numeric-ranges
<length [0,100px]>
indicates a length between0px
and100px
(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 -∞
.
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>
.
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.
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>
.
I'd prefer to explicitly forbid problematic cases, but fine