W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2016

[CSSWG] Minutes Sydney F2F 2016-02-03 Part I: 2017 F2F Meetings, Scroll-linked Animations [css-animations]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 23 Mar 2016 20:00:19 -0400
Message-ID: <CADhPm3tPPG+1N=gyyvEJdZ3KMNTsCV_c4iOsxREUmegBuke6Rg@mail.gmail.com>
To: www-style@w3.org
Cc: public-fx@w3.org
=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


2017 F2F Meetings
-----------------

  - All possibilities were tentative, but the proposals were:
      - January or February will be US or Europe
      - Spring 2017 Japan
      - Summer 2017 possibly TPAC, depending on TPAC's timing

Introductions
-------------

  - This discussion held no technical details.

Scroll-linked Animations
------------------------

  - Due to increased interest, the group revisited a demo that dino
      gave back in 2014 on how to handle scroll-linked animations
  - In the time since the demo, there has been in increase in usage
      of scroll-linked animations as well as the Houdini effort
      which may make it easier to support use cases.
      - As an example, exact pull-to-refresh behavior is likely out
          of scope, but it can be made easier.
  - There were several different aspects that need to be addressed
      in order to spec this.
      - Should have triggers be pre-transform.
      - Anchor points need to be carefully defined in order to
          prevent undesirable behavior.
      - This may generally have performance issues but, like custom
          layout, authors will work out how to use it performantly.
      - Parallax triggered animations will need to be supported.
  - The group went through a list of scrolling use cases shane had
      prepared:
https://github.com/w3c/css-houdini-drafts/blob/master/scroll-customization-api/UseCases.md
  - Dino will take his original e-mail and turn it into an explainer
      document.

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/sydney-2016

Present:
  Nikos Andronikos, Canon
  Rossen Atanassov, Microsoft
  Takao Baba, BPS
  L. David Baron, Mozilla
  Amelia Bellamy-Royds, Invited Expert
  Brian Birtles, Mozilla Japan
  Bogdan Brinza, Microsoft
  Bert Bos, W3C
  Tantek Çelik, Mozilla
  Erik Dahlström, Invited Expert
  Emil A Eklund, Google
  Elika Etemad, Invited Expert
  Jihye Hong, LG
  Joone Hur, Intel
  Dean Jackson, Apple
  Brad Kemper, Invited Expert
  Peter Linss, Hewlett-Packard
  Cameron McCormack, Mozilla
  Edward O'Connor, Apple
  Simon Pieters, Opera
  Xidorn Quan, Mozilla
  Francois Remy, Microsoft
  Florian Rivoal, Vivliostyle
  Hiroshi Sakakibara, BPS
  Doug Schepers, W3C
  Hyojin Song, LG
  Alan Stearns, Adobe
  Shane Stephens, Google
  Jet Villegas, Mozilla
  Greg Whitworth, Microsoft
  Steve Zilles, Adobe

Regrets:
  Tab Atkins, Google
  Dongwoo Joshua Im, Samsung Electronics Co.
  Dael Jackson, Invited Expert
  Chris Lilley, W3C

Scribe: tantek

2017 F2F Meetings
-----------------

  Florian: Not a solid offer, but I can try to co-host 2017 April.
  astearns: We have Europe in the fall (TPAC 2016), probably Japan
            in the spring.
  astearns: As much as I like Sydney in January, might be better to
            have January in the US next year.
  fantasai: Possibly Europe in January?
  astearns: There's a possibility of glazou desiring to host next
            February.
  astearns: Maybe October 2017.
  fantasai: When is TPAC?
  Bert: Probably later in 2017
  astearns: With TPAC in September, then meeting in April [2017]
            that's a long time in between.
  fantasai: Maybe January/February 2017.

  astearns: Main thing is fixing the location for the next meeting.
  dbaron: What I'm writing is Jan/Feb US or Europe.
  dbaron: Spring 2017 possibly Japan.
  dbaron: Summer 2017 meeting likely if TPAC late.

Introductions
-------------

  [This discussion held no technical details.]

  astearns: Plan for the morning is FX in this room, text in the
            morning.
  shane: We're going to break out and talk about scrolling and
         animation effects.
  dbaron: I think that also requires knowing what the other agenda is.
  Florian: (reads from wiki)
  <tantek> https://wiki.csswg.org/planning/sydney-2016#wednesday-am

  [At this point the room split. What follows in this section of the
      minutes is one room; the next section of minutes will be from
      the other room.]

Scroll-linked animations
------------------------
Scribe: birtles

  <birtles> https://lists.w3.org/Archives/Public/www-style/2014Sep/0135.html
  shane: 2 years ago at TPAC dino presented nice demo of
         scroll-linked animation effects, with email to back it up.
  shane: It seems like there's some interest in looking into that
         further.
  birtles: Yes, that's right.
  shane: There's interest from us as well.
  shane: It seems like we should revisit that spec.

  dino: Let's not get too hung up on the spec in that email.
  dino: The syntax isn't that important.
  dino: What's important is that, given that it's 1.5 years ago,
        think about, "what's happened since?"
  dino: An increase in a sites that use scroll-linked effects.
  dino: On the other hand, we have Houdini which is trying to define
        a very low-level way of overriding and having complete
        customization.
  dino: I suggest our goal is to think, "is there a subset of stuff
        that we can agree upon to address the common use cases?"

  dino: In Web Animations and which is compatible with Houdini,
  dino: and I think parallax, which is just one example.
  dino: Another is animations, starting or stopping based on the
        position you hit in a page.
  dino: There are other options like having animations that only
        trigger once, or every time, or only in one direction.
  dino: If we address these common cases, but not the really complex
        ones like pull-to-refresh,
  dino: It seems simple but is actually quite complex.

  shane: So do you think pull-to-refresh is out of scope?
  dino: I think we could support part of if.
  dino: I think our goal should be to make it faster that what you
        can currently do with javascript.
  dino: i.e. the bits as browser vendors we can accelerate in some
        manner.
  shane: To the extent that these bits are useful for the complex
         cases like to make pull-to-refresh smooth, natural, fast
  shane: even if some parts of it are running on the main thread
  shane: e.g. having animations that run to completion running on
         the compositor
  shane: and parts that stick to your finger.
  shane: But run transitions between different types of behavior on
         the main thread
  shane: and later Houdini can fill the gaps or we can introduce
         some declarative syntax for it.

  dino: The email I sent does seem to work pretty well for parallax
        effects.
  dino: Really it comes down to (1) when an animation starts/stops
        based on scroll, (2) using scroll as input to the animation
        instead of time.
  dino: It got tricky when you have to choose scroll context:
        container or page.
  dino: I was a bit scared that the syntax would get complicated
        when you have animations that only work in certain cases
        (e.g. only fire once) or when running on iframes.

  shane: Would it be fair to capture the simple things in CSS to
         keep things simple and cover 80% and accept that you have
         to fall back on Web Animations for the complex cases?
  dino: I agree with that.

  shane: Something that I should bring up, Ian Vollick was concerned
         about not considering the most complex use cases.
  shane: Before we implement, I think we want to experiment to make
         sure this does get us on the right path.
  dino: The right path to what?
  shane: To support more complex things like pull-to-refresh.
  dino: While pull-to-refresh might not be what we want to do, the
        primitives should still be useful for that.

  Rossen: We looked at this post-TPAC and there has definitely been
          internal interest.
  Rossen: The things you guys say resonates with me.
  Rossen: However, we shouldn't kill the great in pursuit of the
          perfect
  Rossen: and we should admit that the perfect might not come.
  Rossen: People will keep inventing new patterns.
  Rossen: There are things like position observer and all kinds of
          other triggers that are starting to become more readily
          available for content creators
  Rossen: and I'm curious, besides basically being able to express
          the timeline as scroll-position, was there anything else
          that was actually needed to be able to build all these
          things?
  dino: No.

  Rossen: When you were experimenting, the one thing that appears
          difficult is scroll positions are fairly dynamic.
  Rossen: Time could be changing in terms of measure underneath you.
  Rossen: If you scroll somewhere and there are all kinds of layout
          updates, your 'time' becomes very unstable.
  dino: That was part of roc's feedback.
  dino: He liked the idea but was concerned about the animation
        affecting the animation (by affecting layout).
  dino: I pointed out that transitions already have this problem
        with hover.
  dino: You can have animation that changes layout which causes the
        scroll trigger to not have fired etc.
  dino: That bit is very worrying.
  shane: Because we did that with transitions, it may be simply too
         late to fix this problem.
  shane: We can think about a model where a triggered transition
         completes, and then reverses.
  dino: That's not so different from just doing it immediately.
  zcorpan: Do we actually need to fix that in transitions?
  shane: A lot of people have pointed it out that its a problem with
         the transitions model.

  dbaron: What sorts of cases are you worried about with this?
  dbaron: Some examples of scroll-linked animation is where there is
          content that changes while you scroll down, and even if
          that container resizes...
  dbaron: I guess, is part of the problem that changes are linked to
          scroll position that might not be consistent in terms of
          content that is animated?
  zcorpan: If you have a parallax, and the animated content
           overflows and the scroll extent changes, then the
           animation time would change.
  dbaron: It wouldn't happen if you used 3d transforms, since the
          scroll extent wouldn't change...
  dino: But people want pixel perfection.
  dino: Using perspective to do parallax is tricky for a designer.
  dino: If they have a 100-high viewport, whole of the page, 200px
        image... if they want to do it with perspective they have to
        do a lot of math.

  dbaron: Is there a way we can make the scroll extent right?
  shane: Can fix the timeline to the pre-animation scroll, so if
         animations change the scroll size then the timeline gets
         longer but the values stay stable.
  dbaron: I think there's a variant of that that's ok, e.g. tie the
          timeline to the scroll extent when scrolled to the top.
  dbaron: But I don't think that works when the window is resized.
  Rossen: In the start state of the animation, you have a timeline
          that is expressed in terms of the scroll distance that you
          have
  Rossen: then you can say that the scroll speed becomes fixed.
  Rossen: So say that initial scroll distance is n.
  Rossen: If n becomes 2n, then you say we don't care, since the
          animation speed is a fixed ratio of n
  Rossen: (i.e. timeline speed).
  Rossen: The other way is to make it relative so that if the scroll
          size changes (e.g. infinite scroll case), that relative
          measure over n also changes.
  Rossen: In either case I think we can come to a stable state.

  dbaron: One thing I'm worried about is having animations that are
          tied to exact sizes.
  dbaron: What I'm wondering is, is there a way to define these
          animations in pieces?
  dbaron: So you say, "I have this thing in the middle of the
          scrollable area and I want to define how just this piece
          moves within its scrollable container"
  dbaron: without defining it as a master thing as a position of the
          scrollable container.
  dino: I think my original proposal has that,
  dino: you're scrolling down the page, when you hit a point, you
        have a negative translate that applies after a trigger point
        is hit and finishes when another trigger point is hit
  dino: and the animation is just a percentage of that distance.
  dbaron: How do you define those trigger points?
  dino: In the demo, it uses abspos, but you could do it as a
        percentage of an element
  dino: or percentage of the visible viewport.
  dino: Basically you want it to run when the element comes into view.

  Rossen: How do you fix the reentrancy problem?
  Rossen: If the element that you're animating changes the size of
          the scrollable container...
  dbaron: Can the triggers just be pre-transform?
  dino: Yeah, that was the idea.
  dino: Maybe you need to choose that.
  dino: If you define your triggers to be relative to the viewport
        then it doesn't really matter if something changes the height.
  shane: I think you want to establish anchor points that are fixed
         independent of the scroll position.
  shane: The anchor points are points of reference between a scroll
         axis and a time axis, i.e. seconds to px.
  dino: So we're solving the parallax problem at the same time here
        but there are other cases where you simply want to trigger a
        time-based animation based on scroll-position.
  Rossen: You don't need an anchor point in that case.
  shane: The animation is still anchored in that it comes into
         effect at a certain point but its progression is not tied
         to scroll position.
  dino: For the simple case, of fire-once animations, we need a
        trigger and some way of specifying that.
  birtles: 3 levels: (1) fire once (2) fire multiple times (3) tying
           to scroll progression.
  dino: The third part of the email was additive animations.

Scribe: dbaron
  shane: For circular references, prefer variables pattern of bulk
         invalidating rather than SMIL algorithm.
  [discussion about avoiding scroll container size change]
  shane: Want to avoid more things that force scrolling back to the
         main thread.
  dbaron: I think if you want that, the restrictions would mean
          wanting a spec that's limited to parallax rather than
          general scroll-linked animations.
  dino: I think people will discover how to use this performantly,
        even though using it generally has performance issues.
  shane: I can live with that; similar to custom layout.
  zcorpan: We can communicate what's fast.
  dino: So can developer tools.

  shane: Can some animations run a little bit out of sync so that
         scrolling stays on compositor?
  dino: e.g., changing background color?
  dino: Changing colors with scroll is probably subtle-enough and
        people won't notice being out of sync.
  birtles: Except step timing functions.
  shane: But what if you explicitly ask for an async timebase.
  dino: devtool could show which animations linked to scroll run on
        compositor.
  dino: If you animate a transform and a background-color, we have
        to make sure they start/finish at the same time.
  dino: e.g., if you animate left and translate at the same time, we
        don't necessarily animate left at 60fps even though we do
        for the transform.
  birtles: We (Gecko) don't run transform on the compositor for
           certain other animations on the same element, but no ties
           for different elements -- maybe animations groups in
           future.
  shane: The biggest issue is animations being retriggered that
         could potentially form a loop, and parallax effects causing
         animations to wobble like transition+:hover
  dino: Parallax wobbling people will understand; people understand
        wobbling in transitions.

  shane: Is demo JS or native code?
  dino: Native code.
  dino: One use case we haven't talked about was scroll effects like
        what Jihye showed scrolling into round display, scaling up
        and down as scrolled into/out of round display
  Rossen: Aligns with this model.
  zcorpan: We probably don't want linear scaling.
  dino: We haven't talked about timing functions, which could get
        close enough for that effect.
  shane: I have a list of scroll customization use cases, maybe
         worth going through them.
  Rossen: Was the round display demo yesterday JS or Android code?
  Hyojin: JS.
  dino: One reason I implemented it natively was to show it could
        improve scrolling on the iPad, where slow scrolling path is
        noticeable (big screen, touch, low power)
  shane: That being a successful experiment was a good sign.

  [shane presents
https://github.com/w3c/css-houdini-drafts/blob/master/scroll-customization-api/UseCases.md]
  [looking it Hidey Bars]
  shane: I don't want to use these cases to stop us moving forward
         on parallax; just want to look over these to see if there
         are simple things we can add to the spec that would make
         these a lot easier.
  shane: Hidey bars and pull to refresh have implicit state machine
         that needs to be run on main thread in JS, and cost of
         having that means you need to bounce between main thread
         and compositor thread when deciding to establish new set of
         animations.
  shane: Compositor parallax and compositor triggered animations
         reduces jank points for these, but doesn't eliminate jank.

  [rubber banding]
  dino: This could probably be approximated, but really, given
        amount of scroll as input, you're modifying how much
        viewport. It's an effect on scroll.
  shane: Can scroll be an animation target?
  dino: Point 3 (animate back) and point 4 (momentum deceleration)
        are hard.
  dino: Keep rubber banding as maybe, await polyfills?
  Rossen: Skip snap points; already have declarative way.
  Ojan: Extensibility point -- you might disagree with decisions CSS
        WG made and want to do things differently.
  shane: Snap points require animating scroll -- can't now -- but
         would like to.
  shane: So dead end until then.

  [pull to refresh]
  ojan: Rubber band plus.
  shane: On some implementations flicking can cause pull to refresh.
  ojan: At least seeing the thing, maybe not commit.
  dino: In most cases as pull-to-refresh, there is an animation
        based on scroll position.
  shane: But this is scroll position going negative.
  ojan: More complicated state machine than hidey bars.
  shane: But still fundamentally a state machine.

  [custom scrollers]
  shane: I think we handle custom scrollers completely

  [retargeting scrolling]
  dino: There might be easy declarative solution to this but not
        about animations.
  shane: But web animations need to be able to do scroll animations.

  [disable scroll chaining]
  shane: Outside of scope of parallax api.

  [custom scroll limit]
  [custom overscroll]

  shane: We need something that's more than dino's email, maybe an
         explainer document derived from it.
  dino: Not at all tied to what I wrote.
  shane: dino, want to start with that and we can then bikeshed on
         the syntax.

  ACTION dino to turn email into an explainer doc
  <trackbot> Created ACTION-92

  shane: Others can help turn it into a spec once that happens.
  shane: Want help with web animations api...?
  dino: Important to have web animations equivalent and ultimately
        (when houdini specs exist) defined in terms of JS that you
        could implement in a scrolling worker.

  <birtles> I actually tried to work out the web animations api a
            long time ago but got stuck, probably because I thought
            scroll timelines would be re-used
            (https://wiki.mozilla.org/Platform/Layout/Extended_Timelines)
  <birtles> for animation-behavior, from Dean's proposal, we have
            something similar in CSS Animations 2 now:
            https://drafts.csswg.org/css-animations-2/#animation-composition
  <birtles> when I tried to map Dean's proposal (or something
            similar) to Web Animations I ran into trouble because I
            was trying to re-use ScrollTimeline objects
  <birtles> it got messy trying to use an Animation's playbackRate
            to map seconds to scroll timeline's units
  <birtles> but I think if you create a new ScrollTimeline for each
            application you can probably avoid that
  <birtles> (also, I want to rename animation-timebase to animation-
            timeline)

  Rossen: Going back... scroll limit used for being able to create
          infinite scrolls. Mostly for list view controls. Where you
          control amount of content that you have, and as you're
          building ahead, want to constrain scrolling to some
          position so you don't scroll to content that's not ready
          yet.

  shane: Dino, want help with web animations api?
  dino: Yes but not yet. Won't get to it until at least next week.
Received on Thursday, 24 March 2016 00:01:17 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 24 March 2016 00:01:18 UTC