[css-values] "explicitly undefined"

[annevk]

It would be better to use Infra's implementation-defined term for the language introduced in 328ddb3. It's also not exactly undefined as hopefully only one of two behavior is allowed (and thus can be tested for). Crashing doesn't seem exactly acceptable here.

cc @emilio @tabatkins @jfkthame @Loirooriol @dholbert @CanadaHonk

[annevk]

I guess I should also note that I'm a bit worried that leaving this choice up to implementations will essentially require market leader behavior, but perhaps it's an extremely unlikely thing to end up relying upon?

[tabatkins]

No, the issue is that literally any numeric result is valid (the whole range from infinity to negative infinity), depending on how close your internal representation is to the asymptote and whether it's slightly smaller or slightly larger. It's inherently untestable without specifying an internal numeric representation, which CSS has intentionally always avoided, to allow impls to use more or less precision, and different types of precision, in various places for optimization reasons.

(You can write tests for this in JS because it's defined in terms of IEEE 64-bit floats.)

Happy to switch over to Infra's term, tho. We use "undefined" or "explicitly undefined" in several places in CSS and have for years, but converging on language is generally good.

[tabatkins]

Lmk if this edit is an acceptable resolution to your issue?

[annevk]

I suspect that in practice websites will end up depending on a particular representation and implementations will be somewhat forced to use that, but I guess we'll see.

[tabatkins]

If that ends up being the case, we'll deal with when it does happen. (In the meantime, the request to make it undefined was by Firefox, and they're the ones of the Big 3 engines that are most at risk of freeze-in here, so I'm happy to let them make that decision.)