Re: [w3ctag/design-reviews] CSS calc-size() function (Issue #955)

* I just answered the first part of your first question about why not to allow mixing in https://github.com/w3c/csswg-drafts/issues/626#issuecomment-2121525106 , 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 https://github.com/w3c/csswg-drafts/issues/626#issuecomment-1863238679 and https://github.com/w3c/csswg-drafts/issues/626#issuecomment-1863371468 , 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 https://github.com/w3c/csswg-drafts/issues/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.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/955#issuecomment-2121557515
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/955/2121557515@github.com>