W3C home > Mailing lists > Public > www-style@w3.org > January 2015

[CSSWG] Minutes Santa Clara F2F 2014-10-28 Part V: Animations, Scrolling Effects and Primitives

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 2 Jan 2015 09:56:22 -0500
Message-ID: <CADhPm3ujZdYj4VnLQ1SC0fx3=0=ZTiwonvuXL7MBR-SoRFCKGQ@mail.gmail.com>
To: www-style@w3.org
Animations, Scrolling Effects and Primitives

  - RESOLVED: start work on Animations level 2
  - Additive Animation will be a part of Animations level 2.
  - Using Animations to smooth out scrolling effects had a lot of
      support and there was substantial feedback to be put in a more
      concrete linguistic proposal.
      - One expressed concern was that scroll effects need to be
          able to be turned off by the user.
      - rbyers presented his proposal to create a set of primitives
          in order to allow developers the ability to be innovative
          in their designs without resorting to building mobile-
          native apps. In specific, he proposed:
          - scroll-delay which lets you do anything on the main
              thread, with sync
          - beforescroll which lets you just intercept scrolls - you
              get an event when there's a "scroll intention" from
              the user
      - volick also presented his set of proposals and there was a
          lot of interest in potentially being able to control a
          bunch of animations with UI Worker, which lets you do some
          things on the scroll thread, with synchronization.


  Scribe: dael


  plinss: Let's get started.
  dino: The topics we had discussed in this section were some
        animation features related to scroll, the before-scroll
        event, and the scroll snap points.
  dino: We can go through in order. From the CSS wiki is the
        proposal of three things related to animations. I don't have
        a demo for animation behavior so we can start with that.

Additive Animations

  dino: If someone can paste the link in IRC. This is adding what's
        called additive animations to CSS animations
  <astearns> http://lists.w3.org/Archives/Public/www-style/2014Sep/0135.html
  <astearns> (animation-behavior: add)
  <fantasai> I'd like to suggest animation-behavior ->

  dino: If you have an animation on a transform and a second on that
        transform, it overrides the first animation and the element.
        So this property is if it replaces or adds. So if there's a
        rotation animations and you add enough it would combine.
  dino: There was a proposal for cumulative and additive.
  birtles: The cumulative is if it adds and repeats on itself.
  dino: So like a bouncing ball where you'd like it to bounce and
        then continue.

  smfr: Does this mean we have to spec which properties are
  dino: Yes. Web animations has done a good job of that. Most aren't
  birtles: Or it's just replace.
  smfr: So if it's absolute 10 pixels, can you add less?
  dino: If it's additive they add, color adds component-wise. If
        it's a transform they multiply the matrix

  dino: I guess the question to the group is, is this in animations
        level 2?
  dbaron: One thought is we have had other cases where we want
          additive cascading. I don't think that's an objection but
          it's related.
  TabAtkins: I think that falls to a different spot unless it's
             addition over lists. I can't think of additive values
             where you have two lists and you add to append.
  dbaron: Filters and transforms.

  birtles: The other feedback was the name.
  dino: I should care, all my proposals I don't care about name. It
        should be animation-composite.

Scroll-triggered Animations

  dino: So the scrolling part. Part of the e-mail had a proposal for
        a two-property one: that's when the animation starts. The
        default is it starts when it's applied. I called that
        animation-trigger. The other was the timebase.
  dino: One of the major performance things is to make scrolling as
        smooth as possible. The current web trend is to do fancy
        scroll things and that makes pages scroll slowly. They do
        this by making a JavaScript that listens to every scroll.
  dino: Doing something by animation delay you have to know when a
        user gets there. I added this one property,
        animation-trigger, when you scroll to this value, but it
        could take other values.
  dino: So as the target element hits the top of the page, an
        animation happens. It's the beginning of the animation and
        runs like normal. You can animation any old thing.
  dino: Once you have the idea of being able to map an animation to
        start at a scroll point, you can take the time domain and
        map to the physical domain, so I've got a start and end
        value and as I scroll up and down I'm going through time. I
        can do that with different keyframes or different mappings.
  dino: You can get nice timing function on scroll. Once you have
        this you can have animation on any property. I've got a
        target that's aligned with the top of the element.
  dino: One of the awesome things is because we know what's going to
        happen in advance we can do this in the compositing thread.
  dino: If you look at the apple.com website on the new iMac you hit
        a point where it scrolls and then becomes mostly sticky, but
        drifts a bit.

  dino: So the e-mail has better specifics.
  florian: What I've seen is you scroll to a point, there is
           scrolling to a time mapping, but until you hit the end of
           the animation you disable scrolling.
  dino: I want to add the minimum number of properties to get as
        many cases as possible.
  dino: You might have two animations, both triggered at this point,
        one which allows you to scrub through time with scroll and
        one that switches to sticky.
  dino: The common one is when things fly in, you don't want them to
        fly out when you scroll up.

  dino: So a common case is you want to run each time and what
        happens when you skip over the trigger, like a scroll to. I
        think it addresses a lot of the common things. It should be
        completely compatible with web animations. I don't think it
  dino: In the proposal I said this is mapping the animations
        timeline to scroll, but you could map to a media element. Or
        a more common option is you have a live stream that stops
        with hang.
  dino: Another thing I put on the list was the Onion's website
        where it says how far in the document you've progressed.
        We'd be able to do that with this script by saying the
        animation runs from 0 to 100 and it is body start and body

  shans: What kind of property can you animate when you use this?
  dino: There is a big issue. This could have animations trigger
        themselves. If you animate the size of the object it's
        annoying, but we have that already on hover.
  shans: That means you can animate the margins.
  florian: It's not slower than in script.
  dino: Or animations already.
  shans: So here the animation is synced.
  dino: There are things we could do in advance that we could sync.
  shans: But no guarantee this would sync.
  dino: Yes.
  shans: Scroll with one value starts an animation, scroll with two
  dino: I think I need a property that has a lot more detail. A
        syntax proposal with different options.

  dbaron: I like the way you do it in the e-mail better than the
  dbaron: What you have in the e-mail that isn't is clear how you
          map the duration to the scroll.
  dino: The animation runs from 0 progress to 1 progress. If the
        begin and end of my scroll is 100 pixels it's percentages.
  dbaron: The e-mail can't spec lengths in the scroll.
  dino: Right. The trigger does. You're right. It's a mistake.
  dbaron: It should have scroll start/end.
  plinss: So it should be on timebase.

  TabAtkins: There had been discussion on this about 2 years ago.
             We're totally cool with this.
  dino: I expect there will be a lot of iteration on syntax.

  zcorpan: Is it useful to have a scroll offset, or is it more
           useful to refer to an element?
  dino: It should accept the same as scroll elements and the calc
        mode. You don't want something to happen when the element
        hits the top of the screen because you don't know the height.
  plinss: What about 5%? I want to make sure pixels isn't the
          default. It's a good usecase, but it's bad for dependency.
  dino: Yeah.

  zcorpan: This seems to only handle scrolling in one direction
  dino: It should be scrolling in both directions. Your first
        question reminded me, at the moment the scroll position is
        to always scroll in its current frame. So if you're in an
        iframe you don't want to be able to determine the position
        for scroll based on your document.
  dino: You can imagine like light buttons where it could work, the
        syntax can get confusing. We might want to start small. I'm
        not trying to deal with every parallax effect, but if we can
        do some things faster, that's great.

  <kip> dino: Would it be possible to trigger based on direction +
        velocity? (Or is this best done another way?)
  <kip> dino: Use case would be a search bar that animates away when
        you scroll quickly downwards

  plinss: Common use case is like when the next button only lights
          up when you hit the next button.
  shans: As a request can we run this with JS.
  dino: In animations, yes.
  plinss: The timebase could be user defined.
  dino: It would drop you into slow scrolling.
  plinss: Here's something we're defining in CSS and you can define
          it within CSS script.
  plinss: Another use case is an animation with media and pauses
          when the media is buffering or the opposite.
  dino: And you might want to sync the timebase to an animation.

  dino: Another part of the proposal once you have triggers you can
        add the ability to trigger an animation from another
  dino: Without editing many, many keyframes.
  dino: The trigger's function syntax is good.

  hober: Prior to going into animation-trigger, you said something
         about behavior, was there supposed to be a resolution

  RESOLVED: start work on Animations level 2

  zcorpan: So the directions should be x and y, or inline and block?
  dino: Yes, it's logical.
  plinss: We need to make sense with overflow and scroll behavior.
  slightlyoff: Probably logical for it to start as you pass.
  plinss: I'm thinking block and inline if you're specifying y you
          might not want to say animation-block. We just want to
          make sure it makes sense when we're done.

  Bert: So how do I turn it off? What's the shortest way to
  Bert: Maybe timebase: auto?
  dino: It's common. People don't like these pages. First they hate
        having so much happen on scroll, then they hate scrolling
  plinss: The discontinuity is annoying.
  dino: I do not like it when I'm scrolling vertical and things move
        horizontal. Web authors will do this stuff either way.
  plinss: We shouldn't make bad things easier.
  slightlyoff: I disagree with that. I think you should give authors
               all the power.
  Bert: I'm fine adding it as long as there's an easy way to turn it
  dino: It's easy to turn it off.
  plinss: I'm with you giving power and adaptability, but there's a
          fundamental part of CSS to giving the user the end power.

Scroll Events and Primitives

  rbyers: Before we do specifics, a general. Over the last 6 months
          we've been talking to people about why they're making
          mobile native apps.
  rbyers: One thing we've heard is that they can get a lot more
          touch sensitive effects. Can I project?
  rbyers: So starting with scroll linked effects. People have been
          doing this forever, but it's urgent for us because some of
          our design requires this and we're having to tell people
          you can't do this on the web.
  <rbyers> https://www.polymer-project.org/components/core-scroll-header-panel/demo.html
  rbyers: This is the simplest example. This is a simple effect with
          a fade and header and I think dino's proposal can do this.
          We implement today based on scroll events. A lot of demos
          you wouldn't notice if you weren't but on a slow device
          you'd notice that the scrolling isn't synced with the
  rbyers: We've got a test page here. If I switch to Safari you can
          see it's not as synchronized. And on a slow phone you can
          really tell. dino's proposal does that.
  rbyers: We want to get more complex. We call this hidey bars. The
          top controls shrink and hide as you scroll. As you scroll
          up the header and footer hides and if you scroll down the
  rbyers: I think dino's proposal would work for this, but I think
          when you take your finger off the device you want it to
  rbyers: Here's an example.
  <rbyers> http://jsbin.com/zosevo/3
  rbyers: We can do this if we listen for touch events, but we don't
          have anything for when the finger is off the touchpad.
          Maybe we can extend the property for active scrolling and
          momentum scrolling afterwards.
  weinig: You can consider non-novel triggers and use new triggers
          to start that.

  rbyers: Then it gets more complex. Lots of native apps use pull to
          refresh. It's scroll linked, but you have to change the
          scroll somehow. We talked about that as scroll
  rbyers: We want to change the notion of scroll top and support
          some kind of customization for overscroll. We want to
          change the relationship between the input and output. In
          this case we have a function that applies friction.
  rbyers: That's what the native apps do. On mobile Twitter did this
          without anyone asking them to because mobile is rich
          enough. I'm worried about defining CSS properties 6 years
          later. I think we need to be able to explain this in lower
          level primitives so app developers don't have to wait.
  rbyers: There's a few other things that make it complicated. One
          of the biggest is changing the relationship of how
          scrolling decides what to target.
  rbyers: If I pull down inside the iframe it'll work as expected,
          but if I pull down it will move which isn't the
          expectation. This is hard to solve because you can't
          communicate between iframes and script.
  rbyers: We need something that acts as the broker between things
          getting inputs and things that will act.
  rbyers: You need to let pull to refresh to either talk to its
          descendants or ancestors.
  rbyers: That's almost the most complex. When you ask what are the
          low level primitives, you realize other common effects are
          also explainable, for example something like the scroll
          effect in Google images, but there could be. If I fling
          it, should it match the native physics of the browser.
  rbyers: Maybe I want to scroll vertically but also have browsers
          top hiding and showing and right now we can't do that on
          the web.

  rbyers: I think that mostly captures the scenarios. I think we'd
          be able to explain overflow-scroll in terms of primitives
          and customize it and how it handles delta's distributions.
  rbyers: What's the simplest low level thing we could add that lets
          us solve these scenarios and also snap points?
  weinig: I don't understand "explain in terms of primitives".
          Overflow scroll can happen in a different process.
  rbyers: Before-scroll offers a composition API to mediate and it
          relies on some kind of composition.
  rbyers: What I care about is the composition API. That could be JS
          on the main thread or a worker, maybe someone wants to
          come up with that in a declarative language. Those are
          implementation details, but if we're going to explain the
          scrolling we've got we need to explain the thread.

  rbyers: On Chrome we've done work where a highly responsive main
          thread where on that limited set we'd be okay losing our
          threaded scrolling, but I think you're saying we should
          aim high.
  weinig: My memory is that it was historically fired but it was
          changed to be not that because it caused bad scrolling.
          The before-scroll reintroduces that with a different name,
          but not a different web.
  rbyers: It lets you opt in.
  rbyers: The a11y web says we need to put the developers in the
          drivers seat. I think it's relevant where you can opt into
          having more control. I don't think every website should
          get rid of threaded scrolling.

  dbaron: You referenced your proposal, but have you talked about
  rbyers: I think it's more useful to talk about the things driving
          it. The details are irrelevant based on these high levels.
          If we're having CSS APIs going through time, that's one
          thing. Then how would we support pull to refresh and the
          problems with it.
  rbyers: Before-scroll says there should be some API that takes as
          input how much the user has tried to scroll and lets the
          app decide how that should be distributed among elements.

  birtles: I think an intersection is to have a script face timeline
           that explains main thread scrolling, but also user
           written timelines that only apply to elements.
  rbyers: You need more than an animation timeline. This doesn't
          address the composition problem.
  birtles: I think it does. Like timing functions.
  rbyers: dino's property lets you control animation objects, but
          scroll offset isn't animatable.
  birtles: Okay.
  florian: It looks like rather than having content you overscroll,
           you can make the content expand for a similar effect, but
           I'm not sure it's good enough.
  rbyers: Yeah, then at the boundary you're switching between
          scrolling and transform and the challenge is that you have
          to deal with switching the physics over. It gets trickier
          from that. We started from let's drive on a low level and
          we tried to aim for a perfect bar. We were using something
          like Twitter on iOS as perfect.

  rbyers: The other point is what Sam was bringing up. If we think
          apps should have control over that we can either let them
          do script on the main thread, we could empower script to
          run UI effects on a different thread, or we come up with
          some non-JS language like if CSS could be rich enough. I
          doubt that it can be captured fully in a declarative
          language, but maybe you could.
  rbyers: We could also let Ian talk a bit about explaining
          scrolling threaded animations.

  plinss: I think there's buy-in to "lets define the primitives". In
          general it's a sound principle.
  plinss: It's something we should drive for. We can argue how it's
  hober: I think this isn't the place to have the argument.
  plinss: If you have a request to see the set of primitives, what
          are they?
  rbyers: We're not far along the implementation, but I already know
          the objections to BeforeScroll are about the high-level
          objects. I know that giving up threaded scrolling for this
          power isn't desirable.
  weinig: Even though it was novel, the rubber-banding and friction
          wasn't actually novel. The primitives depend on what
          you're interested in. So keeping them consistent might
          inform your primitives.
  rbyers: I think there's a good middle ground. I'd be interested in
          saying something like the platform defines overflow, but
          you can customize. We need primitives like keep this
          window open when the user is scrolling.

  weinig: What are the primitives?
  rbyers: 2 parts.
  rbyers: There's threads on each of these, but let me paste.
  <rbyers> scroll-delay:
  rbyers: This allows browsers to develop an API. We've changed over
          time what scroll should sync with and that makes it clear
          for us there is no perfect answer. In IE it's not with
          start of touch.
  rbyers: In Chrome, scrolling is always with start of touch, but
          not all touch moves. You can let author opt into the IE
          behavior. Scrolling is sync with wheel events. It's not
          clear that's right in all cases.
  rbyers: I don't know if it's a major problem with scroll, but it's
          huge for wheel events. Maybe pages should be able to opt
          out and maybe we should be able to say they scroll freely.
  rbyers: There's three possible things to block on. Start, touch,
          and wheel. Scroll-event it doesn't block on
  rbyers: You could say I want my sync events with my scroll. That's
          the gist of scroll-delay.

  jrossi: The use case for disabling the delay for start touch...
  jrossi: It's performance. In IE, we don't have this block
          dependency. The use case for making an even like scroll
          become blocking is these custom effects. You're choosing
          between fast and customizable.
  jrossi: This makes us think more along the lines like animations.
          It would let you get some of these effects. It's possible
          to build a demo of a lot of these that hits 60 frames, but
          I'm not sure that's reasonable for current webdev
  rbyers: That's existing.
  jrossi: If we can find a way like animation triggers that let you
          create the UI without that's goodness.
  rbyers: When you say a lot of these, it's only the first where
          scroll would handle. It's not rich enough for the triggers
          or the hidey-bars. I'm just worried that every new
          scenario will take a few years to make a new CSS property.

  jrossi: I'm not sure we move the web forward.
  jrossi: It's too easy to fall into the "these are mutually
          exclusive". We don't have a pragmatic way for them to play
          with animation triggers. So saying it needs to be a JS API
          because that's the only way to experiment is odd.
  slightlyoff: Why is that odd?
  jrossi: Because if you can't show animation triggers doesn't make
          this a bad idea.
  slightlyoff: I think it's proof this should go first. If you want
               to avoid a world where native apps are beating you to
               the punch...You need to give dev flexibility.
  weinig: That's not proving the point.
  slightlyoff: You've got the example of the Apple website where
               they do things that are slow to do what they want and
               that's bad, but you don't have another way for them
               to behave.
  slightlyoff: Developers today have a whole matrix about taking
               control so they use libraries.
  jrossi: Even the libraries do it poorly.
  slightlyoff: There isn't a uniform model for doing it.
  weinig: They're doing it in a variety of places.
  slightlyoff: But if you're looking at the various ways people are
               working, that there is no way for them to take
               control is the problem.

  dino: You're saying because there's no standard to hook into
        features, that's what makes it slow?
  slightlyoff: It makes it slower.
  slightlyoff: The tech they've adopted may be maladapted for the
               new ways you create.
  slightlyoff: You have evidence of this in front of you.
  rbyers: So if the primary objective is you don't want people to
          choose between more likely performance and control, the
          remaining choices are high level APIs or a primitive that
          explains the threaded effects.
  rbyers: What we're hitting is we want a primitive that explains
          scrolling, but not all of scrolling. The alternative is to
          say if that's an important fast past and primitives are
          important, we need a primitive that explains that. We need
          customization that explains it in an extensible way.

Scribe: TabAtkins

  volick: This example [on screen] is half-baked, but it's to
          illustrate a point.
  volick: If we could find a way of exposing the knobs that threads
          turn, and expose it to JS, then next time one of these
          situations shows up, authors can do things directly.
  volick: [tries to get the demo working on the projector]
  volick: [demo shows some things spinning jankily, others spinning
  volick: For the smooth things I'm twiddling the knobs in a special
          worker-like thing; the janky ones are on the main thread.
  volick: [shows example code]
  volick: What I've done is bind opaque identifiers to these knobs...
  volick: Let me show you main-thread code first.
  volick: I find elements, bind some animated properties. This is
          declarative, so the UA can figure out what you're doing.
  volick: Then these get pushed to the UI Worker, which is a special
          worker that lives on the compositing thread.
  volick: I pass it the tokens for the animated properties, get back
          an "animation context" that lets me adjust these
  rbyers: Since it's on the compositor, when you ask for the current
          scroll position/etc, you get the exact correct value, not
          something that might be delayed relative to what's on
  volick: Of course, this does give the possibility of people doing

  dino: So when you set scalars like that (in the UI worker), you're
        not setting properties directly...?
  dino: You set transform because it's easy to do on compositor.
        What about background-color?
  volick: There's a subset of elements.
  dino: If you set transform there, are you actually setting the
        transform style on the element?
  volick: Yes, but not synchronously. It's plumbed back.
  dbaron: So this requires standardizing the set of things that
          happen on the compositor thread.
  volick: It's not necessarily true that the UI worker must run on
          the compositor thread.

  dbaron: What if one of these workers animates transform and
          background-position? Chrome animates both on the
          compositor thread, Firefox animates transform only,
          background-position on main thread.
  volick: Intent is that you identify the properties that are
          definitely on compositor thread; you'd add judiciously.
  dbaron: I'm more comfortable if we agree here on standardizing
          that list here, rather than just starting with Chrome's
  volick: Sure.
  dino: We sometimes composite based on different state in the page.
  dino: Might not always be consistent.
  TabAtkins: I suspect it's possible to come up with a thing up
             front where it's equivalent to coming up with a JS. In
             that case we wouldn't have to worry about a combined
             list and it would run acceptably in anything that
             doesn't composite. It would make performance testing
  weinig: That sounds like it would make it harder to performance
          test your site.

  benjaminp: I think this has the same risk as dino's proposal, in
             that the input to the animation is limited to what you
             define as the input to your compositor.
  benjaminp: You'll be able to use more operations on the input, so
             it's a bit more powerful than a pure declarative
  rbyers: Ian's API does need more than just scroll offset, but it's
          about more than just inputs; it's about how you process
  volick: If you'd still like the browser to be the broker for
          composing these things, you could make a variant of
          beforescroll that is done on the compositor.
  volick: By forcing the author to express their intent very
          clearly, it lets the UA prepare in ways that you can't do
          with rAF.
  smfr: Do you have a sense that the stuff you can change in
        UI Worker is enough to do hideybars/etc?
  smfr: I think that font-size changes, for example, might be
        desirable in scroll things.
  smfr: I think we'll end up with people doing very complex things
        in their UI Worker that they could have done in CSS.
  rbyers: I think UI Worker isn't trying to solve every problem. You
          can just animate normally.

  rbyers: The scenarios we're trying to copy today, though, are fast
          on native apps for a reason - they don't do font-size
          changes, etc. They take advantage of GPU rasterization,
  rbyers: We think all the scenarios we've talked about can usually
          be done without rasterization.
  dino: So in your example where the text got smaller, it was a
        transform, not a font-size?
  rbyers: Yup.
  dino: So I think there's a nice path from your proposal giving
        complete control, while the CSS one does less powerful
        things, but makes it even simpler.
  dino: I like the idea of investigating this UI Worker.

  MaRakow: I'm curious to see if there's a way to allow the other
           properties to be modified, but you lose guarantees on how
           synchronized they are.
  MaRakow: Even some of the parallaxing effects, they aren't too
           noticeable if they're not perfectly synchronized.
  MaRakow: I'd like to see more detail on your pull-to-refresh.
  MaRakow: Want to see a way to do an off-thread "drag this element
           around the page", or an element with zooming control.
  rbyers: Yeah, touch position is a likely input.
  MaRakow: I think you often want to plug back into native behavior,
           too - native inertia, native rubber-band effect, etc.

  rbyers: That's a good segue into beforescroll.
  rbyers: Note that this isn't about opposed ideas. scroll-delay
          lets you do anything on the main thread, with sync. UI
          Worker lets you do some things on the scroll thread, with
  rbyers: beforescroll lets you just intercept scrolls - you get an
          event when there's a "scroll intention" from the user.
  rbyers: Then you can tell the browser to execute a scroll natively.

  ???: I'd like to see some evolution of the UI Worker proposal,
       based on the examples you brought up.
  ???: Is this new thing going to have arbitrary dom access, for
       example? Or just some limited information?
  volick: I have some half-baked ideas on that.
  rbyers: Yeah. There's an incremental path here.
  rbyers: Even without the advanced scenarios like pull-to-refresh,
          we can do a lot of good. We don't need to block.
  volick: Also useful to talk about the palette of knobs you might
          be able to turn.
  volick: If you can raster fast, maybe you can do colors or
  volick: Worth chatting about that.

  birtles: Maybe define a transform function that takes a scroll
           input and outputs a scroll output?
  birtles: You can run that on either thread as you need to. You can
           use the same architecture as the animations.
  birtles: Then I think there's a path between dino's proposal and
  birtles: As we find effects that are commonly used, we can mash
           those up and prepackage those as we need to.
  volick: I'll have to think a bit more on that.
  <MaRakow> also want to make sure my apprehension is noted in the
            minutes -- I'm interested but want more details

Scribe: dael

  rbyers: Someone asked for the details of beforescroll before. Is
          that worthwhile?
  dbaron: I think it's useful to go into the details before it's too
          late to change...
  smfr: Can you summarize?

  rbyers: Let me project. Here's the link.
  <rbyers> beforescroll proposal:
  rbyers: Right now this is in terms of DOM event, but the high
          level concepts are most interesting.
  rbyers: Let me get the diagram. We looked at our scrolling
  rbyers: You can debate on details, but our chromium architecture
          and abstract the key boxes where the dev has say.
  rbyers: There's three input stacks and the boxes that are red are
          extensibility points where apps can plug in.
  rbyers: Out of that we think conceptually, internally we have
          gesture events that drive the scroll. It's the scroll
  rbyers: Then there's a phase where we take the objects and pass
          them up through the containing blocks. That maps to native
          UI apps.
  rbyers: The idea was to give a hook that's like overriding the
          native view. That could be a DOM that fires beforescroll
          event. I could re-implement overflow scroll by saying I
          have a div that listens to beforescroll events.
  rbyers: The key thing is they have deltas and a method with how
          much the want to consume. It has a delta y of 50 and I
          scroll vertically so I call that and say I want to consume
          them. So beforescroll would bubble up and it would be seen
          by the outer scroller that would apply its delta. It comes
          down to details of diagonal scrolling.
  rbyers: We need to support where a user is dragging diagonally.

  rbyers: There's some that expose missing pieces like velocity of
  rbyers: Some kind of info about the phase of the scroll you're in.
  MaRakow: Is control delta used anywhere else?
  rbyers: Anyone using beforescroll. Some of these just need sync,
          but anything using beforescroll.
  rbyers: We have a version similar to pull to refresh where there's
          an overscroll and the image zooms out a bit. So in that
          case you'd need scroll customization. Also just the image
          search case.
  rbyers: In that case you're replacing the scroll yourself. You've
          just got a regular div which wouldn't normally control the
          scroll. When we see the user tries to control on top we
          use a transform.
  rbyers: But if they get to the beginning and scroll more we need
          it to bubble out. Any time you need to customize you have
          to invoke consumedelta.
  MaRakow: It seems you're trying to emulate elastic.
  rbyers: Not just that. If you think of a normal scroller, there's
          some code that says the user wants to scroll, how much can
          I scroll by? In other methods that's exposed to the
  rbyers: That's not just about getting past the limits. There's a
          difference by asking to scroll and what you can scroll by.

  dbaron: So pull to refresh, do you agree to scroll more than
          normal allowed?
  rbyers: It's less because friction.
  dbaron: You're doing it by setting transforms. You have
          initial-scroll and have content above that top. Do you do
          that by placing content above or play with transforms?
  rbyers: Either.
  rbyers: So you can scroll to a negative offset. Right now our
          native scroller doesn't support that. But it's reasonable
          to have that.

  dino: For rubber banding you'd consume all the scroll deltas,
        inverse translate in the non-scroll, how do the next scroll
        events relate to the change? If you move the element?
  rbyers: Deltas are the inputs. The deltas come from the input.
  florian: So you've scrolled past the limit and then you generated
           scroll events?
  rbyers: A lot of this is handled as a beforescroll event. The
          browser has an overflow scroll div and it should be
          indistinguishable from the one from JS.
  rbyers: There might be security concerns. There might need to be a
          trusted bit, but that's orthogonal.

  rbyers: So we tried to recast our funky scrolling, such as the
          rails for scroll or overscroll effect at the end, we tried
          to describe those in terms of beforescoll. If we're right
          about design we could swap implementations and we can take
          scrolling from the rendering engine core and re-implement
          all the effects we've got. We'd do demos to prove to
          ourselves it's possible.
  rbyers: I think that's the briefest high level overview I can give.

  plinss: We have jdaggett calling back in again soon. Anything else
          on this?
  dbaron: What's next?
  rbyers: The group wants more details about UI worker. I think we
          need to get those in shape and send.
  dbaron: I think you've sent some stuff on beforescroll.
  rbyers: And scroll-delay. One challenge for us is if we feel we
          can afford to wait for UI worker to support this.
  rbyers: We feel some urgency, so it's possible that Chrome may
          proceed with our main thread idea.

  dbaron: I'm not the authoritative person at Mozilla for this, but
          I think roc sounded positive.
  dbaron: I don't know.
  dbaron: Some depends on the state of other browsers. I don't think
          it's a useful end result to only have two browsers
          implement something.
  dbaron: Because webdev can't use it.
  slightlyoff: That's the position they're in now.

  rbyers: A bunch of the effects take advantage of this across
          different browsers.
  rbyers: I guess I would agree with slightlyoff that there might be
          value in allowing apps to do this.
  dino: There's value if browsers do things awesome.
  rbyers: There's also value in the browser doing something horrible
          and deprecating it.

  slightlyoff: They (web dev) were at least able to ship to users
               with that in some browsers.
  bkardell: If you're clever you can ship to all browsers.
  rbyers: There's one site that relies on Chrome, but on Safari you
          get a bar on the top that says install our native app.
  rbyers: I don't think it's bad to allow those choices.
  dbaron: Where I was going is it may be worth it to get these in a
          draft somewhere. It's worth talking about. I don't want to
          see it dropped because you thought no one liked it. We
          should follow up.


  plinss: Okay. Anyone in touch with jdaggett?
  dbaron: He's on IRC
  <jdaggett> here
  <dbaron> jdaggett, ^
  <jdaggett> :P
  [trying to get jdaggett on the phone, Zakim has multiple
    conferences, lots of fiddling]
  plinss: Let's get back to John, I guess.
  plinss: We have snap points.
  fantasai: jdaggett is here, just need to connect.
  plinss: Other conference ends in 5 min, so let's have Zakim time
  plinss: I don't think we have a choice. We can let Zakim time out
        and then get jdaggett.
Received on Friday, 2 January 2015 14:56:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:50 UTC