[css-values-4] Math functions also match mixed types

[cdoublev]

A math function resolves to <number>, <length>, <angle>, <time>, <frequency>, <resolution>, <flex>, or <percentage> [...] If it can’t match any of these, the math function is invalid.

From CSS Typed OM:

A type matches <length-percentage> if its only non-zero entry is either «[ "length" → 1 ]» or «[ "percent" → 1 ]».

[tabatkins]

Any <length> values are valid in a <length-percentage> grammar. We don't need to explicitly indicate that everything that's a length is also a length-percentage; that's part of the definition of length-percentage.

[cdoublev]

My point was that this text almost literaly says that if a math function matches <length-percentage> but not <length>, which happens when it has a percent hint, it is invalid. (In this text, "matches" links to the type checking algorithm in CSS Typed OM.)

I thought it was an oversight, not something obvious that did not need to be explicited.

[tabatkins]

The current text is right. Take a calculation like 10px + 50%, in a context that resolves %s against a length, like the 'width' property:

• per determine the type of a calculation, the type is {length -> 1}, with a percent hint of "length".
• per match a type, a type matches "length" if it's only non-zero entry is for "length" (true), and since the context it's used in allows percentages, the percent hint isn't consulted.

The "match a type" algo has text for matching <length-percentage>/etc that additionally allows a {percent -> 1} type, tho I think that might now be legacy code and effectively unreachable. I should probably just more explicitly fold it into the plain <length> section, as that "If the context in which the value is used does not allow <percentage>" text is basically talking about that case (or rather, the inverse).

[cdoublev]

Ah yes, this branch is obsolete. You cannot get [ percent: 1 ] if the percentage resolves to another type.

[cdoublev]

I am not very familiar with all the features defined by CSS Typed OM: is it possible to successfully add a percentage and a numeric value of another type, if the percentage value does not resolve to a value of this type? Or is the second branch of step 3 of add two types also obsolete? (this has also been discussed a bit).

[tabatkins]

That algo's branch is still valid - when you're doing operations on plain CSSNumericValue objects, you don't yet know the context they'll be used in, so you can't tell whether a % will become a length/etc. So that algo handles unifying types correctly when this is the case - so long as your % doesn't end up resolving against two different types, it's fine to add it to other dimensions.