[CSSWG] Minutes Cupertino F2F 2023-07-21 Part IV: Fold the FXTF specs back into CSSWG?, Scroll-Driven Animations [scroll-animations]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

Fold the FXTF specs back into CSSWG?

  - RESOLVED: Move all fxtx specs into CSSWG github org (FXTF Issue
              #509: Fold the FXTF specs back into CSSWG?)
  - RESOLVED: Move all issues into CSSWG repos (FXTF #509)
  - RESOLVED: Merge houdini github repo specs and issues into
              csswg-drafts repo (preserving history)

Scroll-Driven Animations

  - During discussion of issue #7440 (No-motion / forced-reduced-motion
      issue draft) the group developed an approach to design a way for
      authors say in an animation definition how the UA should reduce
      motion in that animation using common patterns such as skip-to-end
      or step-through-frames. This would allow the author of the
      animation or animation library to define an appropriate fallback
      that gets used when appropriate wherever it gets invoked, making
      it easier for authors to define reduced-motion behavior.
      Flackr will continue work in this direction and bring the issue
      back to the group.


Agenda: https://github.com/w3c/csswg-drafts/projects/38

Scribe: ntim

Fold the FXTF specs back into CSSWG?
  github: https://github.com/w3c/fxtf-drafts/issues/509


  tabatkins: We made fxtf to bridge the gap between csswg and svg,
             but at this point we do not want to hold the bureaucracy
             cost of holding 2 repos
  tabatkins: the svg working group is no longer relevant
  Florian: Yes, do it.
  dbaron: For moving the spec to the other repo, we should preserve git
  dbaron: You can do it as a merge or rebase, maybe rebase is preferable
  dbaron: I don't have strong opinion, I mostly want the history

  smfr: This isn't just about moving the repo, this is also about
        folding the work into the CSSWG
  <fantasai> There's been a lot of confusion about where issues should
             be filed, so this will simplify a lot of that for
             contributors and for ourselves
  [process discussion]
  <dbaron> presumably there's a github issue migration as well
  florian: This is already in our charter, already in our scope

  RESOLVED: Move all fxtx specs into CSSWG github org

  <smfr> 174 open issues

  RESOLVED: Move all issues into CSSWG repos

  florian: Maybe setup redirects?
  tabatkins: redirects are easy
  florian: let's do that
  <emilio> +1

scribe: dbaron

Houdini working group

  TabAtkins: Let's repeat the same discussion, but for Houdini instead
             of FXTF
  fantasai: The TAG is technically not allowed to publish on the REC
            track, so they technically can't be co-publishing with us
  ?: though the TAG still exists
  ?: but has anyone on the TAG who's not in CSSWG been involved?
  <florian> All the TAG members who have been involved in this are also
            CSSWG members

  Rossen: would like plinss's opinion
  Rossen: Last I spoke to plinss about Houdini, I think he wanted to
          continue task force between TAG and CSS WG. And that is the
          definition of CSS Houdini. Whether all the work needs to
          happen in that repo, or we can move the specs into the CSS WG
          repo, we can debate. I'd prefer for him to be part of this
  Rossen: He was one of the original folks behind forming Houdini.
  TabAtkins: Overall point is that collaboration with TAG as a
             bureaucratic split doesn't seem to have achieved anything.
             If the TAG wants to continue working with us, that's great.

  hober: With my Apple hat off and my TAG hat on
  hober: As another TAG member, agree with what Tab said -- to the
         extent that there's productive collaboration to be done
         between TAG participants and CSSWG members -- nothing stopping
         us from doing that wherever the spec's live. TAG doesn't need
         the structure of a TF to do that.
  hober: And, empirically, having that formal structure doesn't seem to
         have bought us anything.
  hober: I don't think it going away would impair the TAG's ability to
  florian: I agree. If we want to have special days of F2F dedicated to
           Houdini topics, can still be done even if single repo.
  florian: Formally the TAG doesn't publish REC-track documents.
  * plinss doesn’t care where the specs or issues live, or even if the
           Houdini TF continues, so long as the intended work continues.
  <plinss> when Houdini started there were interested TAG members who
           weren’t in CSSWG, no longer the case
  <plinss> having them all in one repo also means only one draft server
           instance to maintain
  <TabAtkins> yeah the "one server" thing will be helpful for a lot of
  <TabAtkins> only one url too

  RESOLVED: Merge houdini github repo specs and issues into
            csswg-drafts repo (preserving history)

Scroll-Driven Animations
  scribe: fantasai

No-motion / forced-reduced-motion issue draft
  github: https://github.com/w3c/csswg-drafts/issues/7440

  flackr: I didn't add this to agenda, was already agenda+
  flackr: Where we left off, we thought it would be valuable for the UA
          to reduce motion on websites
  flackr: in a way that didn't require developers to do extra work to
          make it just work
  flackr: We previously, in December, talked about a global strategy
          where there would be some meta tag to say whether site had
          support for animations reduction
  flackr: decided later to make it a per-animation toggle
  flackr: Only development since has been putting together a straw man
          proposal of an animation/transition/WA property
  flackr: to say whether the animation has been written to support
          reduced motion
  flackr: UA could use this to implement reduced motion
  flackr: I was going to put together examples
  flackr: asking around for thoughts

scribe: TabAtkins

  fantasai: The idea is to tag a particular animation as being
            conformant with reduced-motion or not
  fantasai: then if the author wants to change which animations to do
            they'd use an MQ?
  flackr: Yes
  flackr: Don't really like it since in the worse case you're
          specifying reduced-motion twice
  flackr: But as said earlier today we don't want MQ matching to affect
          how we process rules
  fantasai: This seems pretty reasonable to me actually

  smfr: I want some background what UAs do when the user turns on
  flackr: To my knowledge, it's currently entirely on the dev to give a
          reduced motion experience
  smfr: Are you suggesting a world in which UAs suppress all animations
        not tagged with this new property?
  flackr: Yes, it's still unclear how this would work on the platform -
          a different mode, or what
  smfr: I do think it's a valid concern and important

  fantasai: So you're tagging the @keyframes? or what?
  fantasai: Is there a way to simplify some things and say "this
            animation gets dropped if you're in reduced-animation"?
  flackr: We could drop animations that haven't been marked as
          supporting reduced mode
  flackr: but then it would be backwards incompatible break
  flackr: It would break the experience of users who have this option
          turned on
  fantasai: The opposite, the author saying in the tag that "this
            animation is optional"
  hober: The author can already do that with an MQ
  fantasai: They have to do it on each animation property though.
  hober: Ah so this is sugar
  fantasai: Basically
  flackr: Whether this is sugar or not gets into what we do with
          animations in this mode
  flackr: view/scroll animations often display information so they
          can't be ignored
  hober: So are you saying that this wouldn't have any effect on
  flackr: It would change the interpolation behavior, but it wouldn't
          drop them, yeah
  flackr: but if this is fully opt-in then it might be safe to just
          drop things
  flackr: But with an opt-in we're not solving the approach that
          authors aren't thinking about it
  myles: I'm confused

  astearns: I think I'm hearing we have two options
  astearns: The first is Rob's original idea: people can tag animations
            that say 'this is okay for reduced motion'.
  astearns: Second is... wait I'm confused
  flackr: Two options are: 1) UA turns off all animations that aren't
          tagged as supporting.
  flackr: 2) make it easy for authors to declare animations that can be
  myles: So right now websites have all animations. They can use the MQ
         to turn off specific ones.
  myles: Sounds like you want the opposite, off by default (in
         reduced-motion mode) and they can turn specific ones back on
  flackr: Yes, because most authors aren't thinking about reduced-motion
  flackr: so the option really isn't doing anything

  ntim: A concern with this approach is fingerprinting
  ntim: The JS could detect whether you're in forced reduced motion
        or not
  hober: Which is 1 bit more than just preferring reduced motion
  flackr: Yes, they can detect if you're in prefers-reduced today; if
          this is a separate mode it would be detectable as well

  nicole: Rob could you show the demo with the 14 different ways we
          tried to force reduced motion?
  nicole: The goal is great, we want people who want reduced motion to
          get it
  nicole: but the reality of doing it in a forced way is just very
  <flackr> There's a demo at https://flackr.github.io/reduce-motion/demos/phone/
           exploring some automated interventions
  nicole: Our example was apple homepage, a device slid in from one
          side and words from the other and they met in the middle to
          connect them mentally
  nicole: That's why Rob said scroll-driven was hard to turn off,
          getting them to arrive together is very important

  nicole: I'm someone who gets nauseated with animations, and if I can
          control the animation like with scroll it's much easier for me
  nicole: so form a personal angle, scroll-driven is less bad for me
          than normal animations
  nicole: But I also don't really turn on reduced motion, because a
          spatial sense is often an important part of navigating
  nicole: Lots of information from motion
  nicole: This issue deserves a lot of thought and care
  nicole: Maybe no-motion is a hard a11y setting where some breakage is
          okay and worth it
  nicole: but hard to picture it's an everyday feature people browse
          with, considering how much would break
  <jensimmons> Same. I don't turn off animation, because I want it much
               of the time. And for me, when the animation is in
               reaction to my actions, it doesn't bother me. What is
               really hard to take are animations that loop over and
               over and over without any input from me.
  flackr: I think of it as similar to disabling JS

  smfr: I'd be concerned that turning off animations isn't
  smfr: like a fill-forward animation that puts something in place
  smfr: so not turn them off, maybe, but snap them to their final state
  flackr: Exactly that, yes
  nicole: We tried a lot of options yeah, most were terrible
  smfr: One issue is different users have different issues with
  smfr: so maybe the UA needs to decide what the user wants and the
        author doesn't need to know
  myles: A lot of animations are driven by rAF(), too, and we can't
         turn those off
  myles: so you end up in a situation where some animations are turned
         off and some aren't
  nicole: Which will drive people to move their animations to JS
  flackr: Yes, this convo has been had several times on the TAG issue,
          I'm trying to find a path forward
  flackr: hope is that we can find a path that doesn't break sites
  <TabAtkins> (the "tag the animation as okay" thing avoids the "move
              to rAF()", right?)

  fantasai: I wonder if having multiple ways for authors to get around
            this, like tag your animation as what kind of animation
            it is
  fantasai: it won't solve the case of authors that aren't thinking
            about it, but lets us get some reduced motion without
            having to go through all animation properties or
            re-architect styles
  fantasai: so tagging your animations and request handling by the UA
  astearns: Like tag it with something telling the UA how to adapt it
            to reduced motion?
  fantasai: Yeah, like drop it entirely, or skip to end, or jump to
            each discrete keyframe
  fantasai: so like slides can show each keyframe but lose the
            animation between them
  fantasai: so if the author can tell us that, the UA can intervene in
            the way best suited
  <miriam> +1 fantasai's proposal (as an author)
  fantasai: I think a lot of your experimentation could inform what
            interventions are useful
  fantasai: the actions that were reasonable sometimes, even if they
            weren't good for everything
  astearns: And that could be compatible with the UA choosing
            something, and the author overriding

  myles: I think I'm letting perfect be enemy of good
  myles: Fundamental problem is authors don't consider reduced motion
  myles: I'm suspicious that the solution is add more knobs

  miriam: As an author who often thinks about it but wants better
  miriam: Right now I have to build them myself. Jump to end isn't
          simple, I have to set it up myself manually
  miriam: A lot of resets include a jump-to-end keyframe set that's
          added for you; it doesn't always work
  miriam: if there was a quicker way to do it people would use it
  miriam: Not everyone, and it doesn't solve everything, but these
          shortcuts would be really useful
  fantasai: +1 to that
  fantasai: If we improve ergonomics it'll get used a lot more
  fantasai: and if you shift responsibility from invoker to provider of
            keyframes, you can put it into libraries
  fantasai: Authors can use a predefined library of animations, with
            fallback instructions built in, only needs to be done once
  miriam: Also if we've done the research and have a good sense of what
          the solutions are, if I as an author see a list of three good
          solutions that are semantic to particular situations
  miriam: Like skip-to-end is good for content flying in...
  miriam: if I know those are the options I have a better sense of why
          I would use them
  fantasai: You could also use the same mechanism to indicate something
            is important, so keep it even if animations are turned off

  hober: In general I'm sympathetic to this general approach of
         lettings authors sprinkle declarative animation that UAs can
         use to improve the UX
  hober: in this case I'm worried about a few things
  hober: ntim mentioned 1bit of fingerprinting
  hober: but depending on diversity of impl behavior it would easily be
  hober: if there's a gradation of settings for how much animation you
         want suppressed
  hober: From authoring perspective, if there's hints that don't do
         anything obvious, you often run into situations where authors
         develop cargo-culty behavior
  hober: they just add something they were told is a best practice
  <ntim> +1
  hober: so over time the quality of the signal declines, and
         interventions that were initially good have to be thrown out
  hober: So I'm concerned if we game it out a few steps if we actually
         make an improvement

  astearns: Could we make this not detectable, skip the animation but
            make it seem to JS that it does run?
  dbaron: No
  astearns: Ok

  fantasai: One way to avoid is to provide a "simulate reduced motion"
            mode where it shows the effects
  fantasai: so from the privacy aspect, maybe a UA would want multiple
            levels, but we know of 2 right now
  fantasai: At the very least we could make "reduced" better for
            authors to hook into
  fantasai: If devtools is helping to simulate that mode, then you can
            experience what that user would see and you're less likely
            to pick a bad hint
  fantasai: this might not fully solve the problem and we still might
            want to force things, but I think making it easy to get
            some type of result would help the situation
  flackr: there's already an option for that in chrome

  flackr: this discussion was helpful. the TAG said they wanted
          something that devs didn't have to interact with at all, but
          here it sounds like we want something that lets authors help.
  flackr: So we can still have the MQ, and then also make some
          properties that let authors help out.
  flackr: Like animation-interpolation-mode or something like that. but
          I don't want to propose just yet.

  <fantasai> I would propose "reduced-motion: <keywords>"
  <fantasai> Where keywords is things like "drop" or "skip" or
             "discrete" or anything else we think up
  <fantasai> And where "reduced motion" is something you can declare
             inside @keyframes
  <fantasai> or inside a single keyframe

  miriam: I think Tess makes a good point, but I'd say the cargo cult
          already exists
  miriam: A big chunk of keyframes that do one thing and do it poorly.
          providing a better tool makes it more likely people use the
          right thing
  nicole: Generally I like personalization issues. Have to be aware
          that it puts a burden on author testing
  nicole: it gets combinatorial
  nicole: so we need to be thoughtful. I like the idea of skip-to-end,
  nicole: just need to be thoughtful about burden we put on devs

  astearns: Think we'll leave the discussion here and keep working on it
  flackr: This is a change in direction, nicely concrete. I can come up
          with more details around this

Received on Sunday, 10 September 2023 15:51:04 UTC