CSS calc-size() function

[dbaron]

こんにちは TAG-さん!

I'm requesting a TAG review of the CSS calc-size() function.

The CSS calc-size() function is a CSS function similar to calc(), but that also supports operations on exactly one of the values auto, min-content, max-content, fit-content, stretch, or contain. This allows transitions and animations to and from these values (or mathematical functions of these values), as long as the calc-size() function is used on at least one of the endpoints of the transition or animation to opt in.

• Explainer
• Specification
• Tests
• Security and Privacy self-review²: Mostly not relevant since this is adding declarative CSS mechanisms for things that can already be done (slower, sometimes) in Javascript.
• GitHub repo
• Primary contacts (and their relationship to the specification):
  • David Baron (@dbaron), Google, implementer in Chrome
  • Tab Atkins (@tabatkins), Google, spec editor
  • Ian Kilpatrick (@bfgeek), Google
  • Alan Stearns (@astearns), CSS WG co-chair
  • Rossen Atanassov (@atanassov), CSS WG co-chair
• Organization(s)/project(s) driving the specification: Google and the CSS WG
• Key pieces of existing multi-stakeholder (e.g. developers, implementers, civil society) support, review or discussion of this specification:
  • Chromium comments: supportive, see above :-)
  • Mozilla comments: CSS calc-size() function mozilla/standards-positions#1022
  • WebKit comments: CSS calc-size() function WebKit/standards-positions#348
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): Chromestatus, longstanding csswg-drafts issue, longstanding Mozilla bug, longstanding Chromium bug

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: hoping to ship this sooner rather than later
• The group where the work on this specification is currently being done: CSS Working Group
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): CSS Working Group
• Major unresolved issues with or opposition to this specification:
  • There has been some discontent about this not solving all of the problems that people hoped it would solve. It nonetheless solves a bunch of real problems and I think it's worth doing.
  • see explainer for further links / discussion, though I'm not sure any of the issues count as major
• This work is being funded by: Google

[martinthomson]

@hober, @LeaVerou, @plinss, and I discussed this and we have some brief feedback, some of which is really questions.

We have several concerns with the design of this function:

• If calc-size() returns a <length>, what prevents authors from doing something like calc( ( calc-size(min-content) + calc-size(max-content) ) / 2 ) which seems to be the very thing it was designed to prevent? If that is invalid, it seems like a footgun, since these lengths are often passed around in variables, so the error will not be immediately obvious. And if it’s invalid, it begs the question, how is this better than making calc(min-content + max-content / 2) invalid while calc(min-content / 2) or calc(max-content / 2) are individually valid.

• We are concerned with adding a parallel function to CSS that is identical to calc() with the only exception being that it supports an intrinsic sizing keyword. We think that simply allowing keywords in calc() would have been a better design, even if only one keyword type is supported and it becomes invalid when more than one are used (going from 0 to 1 is still an improvement, modulo the above concern). This leaves the door open for supporting more keywords in the future, it means all other math functions that support <calc-sum> (such as clamp()) also support intrinsic sizing keywords, and does not increase the API surface authors need to learn (especially since we suspect it’s unlikely they would ever hit that restriction).

• Looking at the (great) compat analysis, it seems unclear whether this would be a net negative. As @dbaron points out, in most of these cases the result is either an improvement, or a very slight glitch. We are not sure that the reduction in ergonomics that something like calc-size() causes is clearly warranted from this data. But even it were, is introducing a new calc() function the best way to address it? E.g. there are other cases where transitions need to customize the interpolation on a value type-specific basis, e.g. color space for <color> transitions, perhaps some kind of per-transition/animation opt-in would be more palatable?

• We have concerns about backward compatability. E.g. if an author specifies height: calc-size(max-content) (or height: calc(max-content)) then a UA that doesn't support the new behavior loses the height property, requiring the author to specify height twice (or more: height: max-content /* what is wanted, not animatable */; height: calc(5em * ?) /* approximate the size, but animatable (?) */; height: calc-size(max-content) /* this proposal */;)

• Using a calc a function to opt-in to animation behavior doesn't seem readable. A different author seeing height: calc-size(max-content) will not necessarily understand the purpose of the function and may want to remove it to just height: max-content. The effect here of disabling the animation is not an obvious consequence of that change.

[dbaron]

• I just answered the first part of your first question about why not to allow mixing in [css-transitions] Transition to height (or width) "auto" w3c/csswg-drafts#626 (comment) , since I saw it there first.

• I think the second part of the first question and much of the second question (why not just use calc() and make the mixes syntactically invalid) is answered in [css-transitions] Transition to height (or width) "auto" w3c/csswg-drafts#626 (comment) and [css-transitions] Transition to height (or width) "auto" w3c/csswg-drafts#626 (comment) , which describe the original rationale for this choice. (I agree the this definitely has arguments on both sides, though.) However, I think the response to the first question (why we shouldn't support mixes) negates some of the arguments you make about supporting mixes eventually.

• I think that's a misreading of the compat analysis. I found three animations that were clearly worse and would probably be considered unacceptable regressions to the page designers, one that was different but not obviously worse or better, and one that was better. And that was using a sample that was extremely short on animations since it involved only page loading and not user interaction.

• I think developers who pay attention to backwards-compatibility are familiar with the idea of repeating declarations with the one for older browsers first. That said, I suspect the reason you're raising this (that is, the only reason I see that this is different from adding any new CSS feature) is because of the connection to the next point -- that you'd like authors to use a different opt-in so that the backwards-compatibility concern (at least for CSS transitions rather than CSS animations) would be restricted to the animation itself and not the states before and after it. That's a fair point. (That said, the alternative opt-in mechanisms we discussed so far all have tricky issues as well, I think; see below.)

• As a followup to the most recent CSSWG discussion, we opened [css-values-5] Interpolating calc-size() more generally w3c/csswg-drafts#10294 on having an additional opt-in mechanism. (After all, there's no reason that we have to have only a single opt-in; it may well be reasonable to have more than one thing that opts you in to the "new" path.) I think there are a bunch of complex design questions about an alternative, such as:

  • We want to avoid an opt-in that is too "global" because it doesn't work well for web content that mixes components built by different authors (some of which may need the new behavior and some of which may be incompatible with it)
  • Adding to the existing transition-behavior shorthand is too tied to CSS transitions; if we did this we'd need a separate opt-in for CSS Animations and Web Animations
  • Having a separate non-inherited property makes the syntax somewhat disconnected from the animation that requires it; I think mode-switching properties in CSS that have effects on other properties are generally a design mistake, both because of action-at-a-distance (with declarations from different sources combining together) and because they're not tied to the CSS cascade's overriding behavior.

  I think then there are two separate questions: do you think having the calc-size() opt-in is too unreadable to be the only opt-in, or do you also think it's too unreadable to be one of the choices for opting in? I'm not sure from your question whether you think only the first, or you think both.