[css-values] shouldn't be able to resolve to in calc()

[tabatkins]

In #1462, I talk about the problems inherent in letting "number"-typed expressions in calc() ever resolve as equivalent to "length"/"angle"/etc expressions. This was already disallowed in Level 3 calc(), so it was okay.

However, I just realized that Level 3 calc() does allow and to be equivalent, which brings up the exact same issues.

Now, in plain CSS, the difference doesn't really matter - because s can multiply with each other endlessly, it's okay to have an expression like calc(1% * 1%) for 'opacity' (as it resolves to "number"), but the exact same calc() would fail immediately in 'width' (as its type would be length²). Similarly, it would mean that calc(1 + 1%) is valid in 'opacity' but invalid in 'line-height'. This all complicates the rules quite a bit in Level 4 calc(), or Typed OM.

I propose that we amend calc() to prevent from resolving against . This has no practical effect on devs - since and are just rescaled "units" in 'opacity', there's never a need to add them together in calc, or multiply two or more percentages (you can just convert them to numbers by shifting the decimal point, then add/multiply them). However, it drastically simplifies the necessary type-tracking spec text I'm writing for Typed OM (which Level 4 calc() will reuse).

[Crissov]

Aside: We should never have had unitless where real scalars are allowed.

[tabatkins]

Correct, but that's not relevant here - is always a "number" type in calc(); width: calc(0); is invalid, because 'width' doesn't accept in its grammar.

[tabatkins]

Agenda+ for resolution. Also, some trivial testing (seeing if opacity: calc(.25 + 25%) is supported) in Chrome and Firefox shows that they won't be affected by this change, as they currently treat it as invalid anyway.

[css-meeting-bot]

The CSS Working Group just discussed shouldn't be able to resolve to in calc(), and agreed to the following resolutions:

• RESOLVED: Accept proposal

The full IRC log of that discussion

topic: shouldn't be able to resolve to in calc()
github topic: https://github.com//issues/1463
TabAtkins: When you use % in calc it's allowed...you can use it anywhere the usage would resolve a % against another type.
TabAtkins: Applies equally, but per spec it applies to numbers. THis would apply in opacity, for example. Problem is in typed OM when I'm trying to deal with types of expression how we desc in last F2F numbers have an empty type map.
TabAtkins: If we don't allow % against numbers they're easy to handle. It's always somet ype and I can later fill in the type.
TabAtkins: If it could resolve against a number I lose that ability. A % could be a type or none at all and that makes the algo harder to desc.
Florian: Clarification: opacity you have % or umber and it's the same or you have line height where % and number aren't combinable. Are there cases where you have % and number where they're combinable but not same.
fantasai: They're combinable in the sense where # and % in line height ultimately resolve to length.
fantasai: We could, in thoery, allow that.
TabAtkins: There's a reason not to. I'd like to never allow that. There's a reason to disallow that.
TabAtkins: It makes the type of numebr incoherent. It's typeless or has a type. It makes the algo to type check math extreemly more complicated.
For line-height, % and number don't inherit the same: % gets converted to length before inheritance, number is converted at used-value time.
TabAtkins: Big problem in when you multiple unitless. If a number can represent a lneght if you multiple 1 x 2px is it a length or a length suqared?
AmeliaBR: Yeah, and in width, and have that same difference
TabAtkins: There's only two cases wehre this matters, line height and tab size. We could just add a unit. For now we're okay. Calc doesn't allow you to treat a number as a length.
dbaron: I'm not happy about treating # and % the same. # on line-height needs to be distrinct from %
PS, for length + number, there are all the SVG properties to deal with, that treat number as equivalent to px
(e.g., stroke-width, stroke-dasharray)
TabAtkins: They are. This is where % resolves to a number. Opacity is the obvious example. I propose we say a % never resolves to a number type.
fantasai: Does the % value of opacity compute to a number?
TabAtkins: I believe it computes to a number. That's what it has to do. Opacity uses 0 to 1 as a %. The two are eq.
I'm with Tab here. The alternative seems to mean a lot of complexity for no good reason.
fantasai: I think it would be surprising if someone tried to to combine and it didn't work. If you're adding a variable to an inlined you'd have to be very careful.
q+
TabAtkins: I agree. That's why we originally wrote % can resolve against #. But from a pratical standpoint dealing with types it doesn't work. You get an incoherent thing where numbers can sometimes be used as extra values. In the worst case you can never tell what type an expression is if a # shows up.
TabAtkins: If I wasn't writing spec text I wouldn't have suggested this.
ack fremy
fremy: Edge does not support % in opacity. THis is the first time I heard you can. I would be fine saying % doesn't mix with numbers,
TabAtkins: No one, even browsers that allow %, don't allow them to mix in calc. Everyone is consistant in not allowing this, I want to fixt he spec.
astearns: By not allowing we're matching impl.
TabAtkins: Yeah.
dbaron: Some of that is because we don't have a spec ofr calc unit.
TabAtkins: It's a lack of support not a positive we're doing this on purpose thing. But removing it won't cause problems.
s/ofr calc unit/for calc() unit algebra/
% for opacity was a relatively recent addition to the spec
astearns: Objections to codifying this limitation?
RESOLVED: Accept proposal