[css-values-5] Should we keep the single-argument form of calc-size()

[dbaron]

As discussed in https://github.com/w3c/csswg-drafts/issues/10294#issuecomment-2127202025 I think we should be recommending the new interpolate-size property as the mechanism for opting in to using interpolation of sizing keywords via calc-size().

calc-size() currently has a single-argument form that I think was designed to make it easy to opt an animation endpoint in to this interpolation by wrapping it with calc-size(). However, as that comment explains, I don't think we should recommend this form of opting in because of its effects on non-supporting engines during the period when the feature is implemented in some but not "all" engines.

This then leads to the question: should we still have the single-argument form of calc-size() at all? Or should we drop it?

cc @tabatkins

[tabatkins]

I'm okay with dropping it. As you say, the main reason for adding it was just to make it easier to use when you weren't doing anything fancy, just flagging the value to ensure that transitions worked as expected.

[dbaron]

Proposed resolution: Drop the single-argument form of calc-size().

[astearns]

The CSSWG will automatically accept this resolution one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support this resolution, please add a new comment.

Proposed resolution: Drop the single-argument form of calc-size().

[LeaVerou]

My understanding is that calc-size() is useful more broadly than animations. Are there no other use cases?

[dbaron]

The intent here is to keep the two-argument form of calc-size(), but drop only the single-argument short form, which was a convenient way of wrapping a value in calc-size() without having to worry about which argument it goes in. The main use case for that was, I think, being able to say "just wrap a value in calc-size() to make your animation work". It's otherwise a bit confusing, since the current definition is:

If only one argument is given, and it’s a <calc-sum>, then the provided argument is the calc-size calculation, and the calc-size basis defaults to any. Otherwise, the provided argument is the calc-size basis, and the calc-size calculation defaults to size.

By example:

• calc-size(50%) is calc-size(any, 50%)
• calc-size(30px) is calc-size(any, 30px)
• calc-size(auto) is calc-size(auto, size)
• calc-size(min-content) is calc-size(min-content, size)

The proposal here is to drop the first form (where, depending on the value, the single argument is sometimes the basis and sometimes the calculation) and just always require both arguments (basis and calculation).

Note that calc-size(50%, size) and calc-size(30px, size) are also valid two-argument forms. But calc-size(50%, size) is different from calc-size(any, 50%) since the first one is treated like a percentage value and the second one is (mostly) not.

[LeaVerou]

No opinion. As I have expressed before, I think calc-size() as a whole is exposing an implementation wart to authors, and is a concept with no purpose. Whether implementations use separate code paths for each intrinsic sizing keyword is something that should have never made it to author-facing syntax.

[tabatkins]

My understanding is that calc-size() is useful more broadly than animations. Are there no other use cases?

calc-size() is more broadly useful, yes. But single-argument calc-size(), the subject of this topic, is only useful to make it trivial to trigger the animation behavior, a task which is now better solved by the interpolation property.

[astearns]

RESOLVED: Drop the single-argument form of calc-size().

[bramus]

With commit https://github.com/w3c/csswg-drafts/commit/01ac71db027a66993d4d3e1ab22d4e4d579b414e in place, this one can be closed, @dbaron?