1845298 - [css-values] sign() function with mixed relative units it not supported.

Status: NEW

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Tiaan Louw]

sign() functions always resolve to numbers, which means that it should be resolvable during parsing, because only lengths are sent to Gecko so that relative units like percentages and font-relative lengths can be resolved.

This means that sign(10px - 1em) will not resolve in the parser, because the parser doesn't know what 1em is.

Using any other function that resolves to the same unit as it's children, e.g. abs() will resolve abs(10px - 1em) with a font-size: 10px to calc(0), because lengths can be sent to Gecko to be resolved.

Comment 1

[Jonathan Kew [:jfkthame]]

The same applies to percentages, viewport-relative units, etc, right? So sign(100px - 10%) or sign(20vh - 10vw) fails similarly.

(Such units are accepted if they're the only unit involved, as in sign(10em - 5em) or sign(50% - 60%), as that can be simplified without resolving the actual size of the unit, but as soon as they're mixed with another unit, it'll fail.)

Comment 2

[Tiaan Louw]

sign(10em - 5em) would also not resolve. The calculations are done on canonical units. In the case of em we want px. So sign(5em) == 1 would be a wrong assumption. What we want is sign(5em) with fontSize=10 being sign(50px) == 1 or with fontSize=-10 then sign(-50px) == -1. The example is a bit contrived with fontSize being negative, but the idea is that the basis value might be negative. The only "real" case of this being absolute positioning with negative relative positions. (position: absolute; top: -3em)

And because none of the basis values are present at parse time, we can't even calculate sign(1em). Unless of course the type of the field is a length, in which case the calculation is preserved and resolved at a later time when the values in question are available. It will then fail, because the resolved value is not a length, but a number. So really right now the only way to get the sign of relative length to work is calc(sign(1em) * 1px), which coerces the number into a length.

Comment 3

[Jonathan Kew [:jfkthame]]

(In reply to Tiaan Louw from comment #2)

sign(10em - 5em) would also not resolve.

Hmm. Here's what I see in the web console in Nightly:

» x = document.createElement("span");
← <span>

» x.style.zIndex = "sign(10em - 5em)"
← "sign(10em - 5em)"

» x.style.zIndex
← "calc(1)"

» x.style.zIndex = "sign(1em - 5em)"
← "sign(1em - 5em)"

» x.style.zIndex
← "calc(-1)" 

The negative basis issue does seem like it would complicate this; but can font-size actually be negative? I'm not sure that can arise.

Comment 4

[Jonathan Kew [:jfkthame]]

(So in comment 3, is this not being resolved during parsing but later?)

In contrast, mixed units such as 10px - 1em give me "Error in parsing value".

Comment 5

[Tiaan Louw]

You are right. If the units are the same, they do resolve to a value.

Lengths are resolved once we can resolve percentages (that is not during parse time), but relative font sizes, etc. I'm not so sure now. Looks like my understanding of the resolution there is not so good.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

This is kind of expected because otherwise we get a lot of circularity issues that are still unsolved on the spec last I checked? But maybe it's better now: https://github.com/w3c/csswg-drafts/issues/8169 / https://github.com/w3c/csswg-drafts/issues/9517 / https://github.com/w3c/css-houdini-drafts/issues/1080