W3C home > Mailing lists > Public > www-style@w3.org > February 2016

[Houdini] Minutes Sydney F2F 2016-01-31 Part IV: Scrolling Extensibility, Meeting Wrap-Up

From: Dael Jackson <daelcss@gmail.com>
Date: Sun, 21 Feb 2016 15:05:46 -0500
Message-ID: <CADhPm3uHKOHJcgHCXKfMvja24Tsw28x4=bk8YqxV-KSUQizrVQ@mail.gmail.com>
To: public-houdini@w3.org
Cc: www-style@w3.org
  These are the official Houdini Task Force minutes.

         Unless you're correcting the minutes,
        please respond by starting a new thread
           with an appropriate subject line.

Scrolling Extensibility

  - rbyers presented a demo and the use cases that they're currently
      considering for scrolling extensibility.
      - Each of the use cases had follow-up questions, but no one
          objected to the direction the spec if going in.
  - RESOLVED: Flesh out the explainers for compositor worker.
              Experiment more and share data.

Meeting Wrap-Up

  - RESOLVED: Publish FPWD of Worklets Level 1
  - RESOLVED: Publish FPWD of CSS Paint API Level 1
  - The May meeting was discussed and most people wanted to meet
      adjacent to the CSS meeting again.
  - There's hopes that properties and values will receive FPWD
      during the CSS meeting over the next few days.


Agenda: https://github.com/w3c/css-houdini-drafts/wiki/Sydney-F2F-January-2016

Scribe: vollick

Scrolling Extensibility

  rbyers: So I thought what would be useful was to talk about some
          richer scroll customization use cases.
  rbyers: I've written up an explainer that goes over the basics and
          has some code.
  rbyers: Finally, I've got at demo that I can show.
  rbyers: We talked about scrollers with cw, but the key difference
          with hidey bars is that you have to know about scroll state.
  rbyers: There's a bunch of extra complexity with this, but I would
          like to be able to be able to implement our "top controls"
          this way, but it's currently really hard.
  rbyers: Rubber banding is another interesting case. We're actually
          changing how the scroll input effects the output (to
          introduce drag).
  rossen: How's rubber banding different than pull to refresh?
  ojan: Is it a strict subset?
  rbyers: Yeah, there's some fancier stuff you can do with p2r, but
          we usually start with rubber banding as it's simpler.
  rbyers: We tried to build a p2r component for the web that was as
          good as twitter's native and could only get to 90% and
          that informed our approach.
  rbyers: For example, when you start showing the p2r affordance,
          the metaphor is that you're pulling a spring.
  rbyers: If you change direction and the thing that happens isn't
          that the spring contracts, it seems unnaturally.
  rbyers: So you want to have control over who the scroll gets
          shunted to.
  rbyers: We also want to be able to implement scrolling by
          adjusting something other than scroll top.
  rbyers: We want it like regular scrolling in how it composes,
          flings, accessibility, but we want to drive a rotation.
  rbyers: ..for example.
  rossen: I can you show that demo.
  rbyers: <shows the demo>

  rbyers: Currently when people want to implement this themselves,
          they have to re-implement the world in JS and is a part of
          the reason we only get to 90%.
  rbyers: There are other cases where we don't want to change how
          scroll is applied, we want to redirect the scroll to the
          right scroller.
  rbyers: One case we hit was where we hit the bottom of a scroller
          in a fixed:pos element and we don't want the bubbling to
          start scrolling the document..
  rbyers: We want to implement Microsoft's scroll chaining with
          scroll customization primitives.
  rbyers: Facebook says that they use wheel listeners _only_ for
          this purpose (to prevent scrolling the wrong thing).
  heycam: This could also prevent you from zooming in on your map.

  rbyers: <presents a demo showing the android "tongue" that appears
          when you overflow and shows how it needs to know where
          your finger is to glow in the right spot>
  rbyers: err, overscroll.
  rbyers: This is the end of the use cases. There are also some
          links to some other effects at the bottom of the doc (
          added by Florian)
  rbyers: Are we missing any cases? Are there cases we don't care
  <rbyers> Use cases:

  ojan: As I'm skimming through the use cases. p2r in particular;
        I'm not seeing mention of the effect that appears as you
        show the p2r affordance. Is that mentioned?
  rbyers: No, it was missed. There's often a little twister or
  rbyers: <adds prose to the use case live>
  ojan: There's a huge variety of things people do here, which is
        why I bring it up. Maybe they shouldn't, but..
  <rbyers> Explainer:
  rbyers: So here's the start of the explainer.
  rbyers: I'm linking to one popular library, iscroll, that
          reimplements the world.
  rbyers: This has these downsides. 1) no threaded scrolling. 2) not
          hooked into assistive technologies. 3) it's possible to
          get stuck in them (they don't compose).
  rbyers: 4) doesn't feel native; doesn't match platform physics.
  rbyers: For now, we're trying to build on compositor worker. We
          think that this an orthogonal concept and that we should
          be able to disable threaded scrolling.
  rbyers: This is controversial and is currently out of scope...

  ojan: Can I add something most UAs have both a main and scroll
        thread so it has to work in both?
  rbyers: The edge only has one path, right, but can be joined with
          the main thread?
  rbyers: It describes scroll intent, the thing that appears
          directly out of wheel touch keyboard or scrollbar dragging.
  rbyers: The intent has stuff like delta velocity phase etc,
  florian: Does this include things that the user didn't do?
           Programmatically scrolling something, for example?
  rbyers: No. Initially we included things like scroll into view,
          but it didn't help with the use cases.
  rbyers: home/end are kind of special and we don't consider them a
          scroll intent because they're absolute.
  tantek: Arrows can be ambiguous, either scroll or something else.
  <tantek> or directional navigation
  <tantek> per CSS3-UI
  rbyers: Don't worry too much about the details, but we want to
          hook some custom logic that translates the scroll intent
          into scroll application.

  rbyers: Here's an example using the CompositorWorker placeholder
  rbyers: It describes a carousel example that takes the scroll
          delta and applies it to the x rotation.
  rbyers: We have an API that lets you report what amount of scroll
          intent you've consumed.
  rbyers: For example, we may want to shunt horizontal scroll to one
          elem, but vertical scroll to another.
  rbyers: Anyone have a question on the big picture, pulling out the
          intent to scroll.
  smfr: It seems weird that you manipulate the scroll intent. Why
        not return the delta?
  rbyers: Part of the reason is historical to support bubbling. but
          if we start scroll latching, this may not be necessary.
  rbyers: If we really do want to affect many scrollers,
          conceptually, we want to imagine the scroll intent flowing
          through the scrollers.
  smfr: I think you could do something functionally the same by
        returning the used delta.

  ojan: Do you support changing velocity?
  rbyers: We only support changing the delta currently.
  rbyers: If we scroll by one pixel, do we really want to let you
          scroll 100 and potentially show the top controls.
  rbyers: So we've restricted it to be consuming an amount from the
          given delta.

  esprehn: Can you explain how p2r works in this model?
  rbyers: There's a bunch of models, but in our primary demo, once
          you get to the point that you show the affordance, we
          transform the whole scrollable area..
  esprehn: That will shift the scrollbar.
  rbyers: Maybe that's not the right way to do it. Let's talk off
  esprehn: You want to show padding..
  rbyers: We could imagine scrolling at 100 and then scrolling to
          the top adds friction.
  rbyers: Maybe the right place to start is rubber banding because
          it's simpler.
  florian: There's an interesting round display use case. The top is
           narrow so you want to squish content at the top of the
           display as it scrolls by.

  ojan: That whole discussion made me wonder if we should just allow
        negative values.
  smfr: We report them but it sometimes causes problems because the
        code doesn't expect it.
  rbyers: If you opted in, might be ok.
  ojan: In addition to that we could let it accept negative values
        if you set it.
  ojan: Don't see why not unless it's an egregious compat problem.
  esprehn: Is there any standardization behind the Microsoft
  esprehn: In particular the chaining one.
  rbyers: We wanted to build it on the primitives, but if it was
          urgent, we could implement it.
  esprehn: Something as obvious as turning off chaining would be
           useful, in addition to scroll customization.

  rbyers: <prepares to show demo>
  rbyers: <demo is of a cylindrical scroller that turns in response
          to scroll>
  rbyers: Notice that if you scroll in the y-direction, it scrolls
          naturally using platform scroll logic + fling.
  rbyers: Scrolling in x rotates the carousel.
  rbyers: <steps through the code>
  surma: By eating scroll x means you'll never "get to the end"
  rbyers: Yeah, because we've reimplemented scrolling, we can scroll
          forever in that direction.
  rossen: And if you want to allow chaining...
  rossen: For example if after 180 degrees you want to bubble.
  rbyers: Yeah, you add a conditional to stop consuming deltas after
          180 degrees and it will propagate.
  smfr: Naturally you would want this to come to rest on a cat in
        the carousel.
  rbyers: Yeah, we haven't hooked snap points into this.
  rbyers: We may be missing primitives about exposing platform
          curves, but currently we just take over fling when it
  smfr: But if you're combining this and scroll snap, which comes
  rbyers: There's interesting API decisions. We may have multiple
          scroll modifiers. You may want the consumer to compose both.
  rbyers: We have this problem with other Houdini APIs because we
          don't have CSS compositor.

  rbyers: That's about all I've got. Our implementation does have
          some more complexity. "distribute scroll", for example,
          which is related to scroll bubbling.
  rbyers: The document passes the scroll delta to each scroller in
          the chain so that they have an opportunity to act.
  rossen: What happens if you call scroll to?
  rbyers: It's not an overflow scroller, so as far as CSS is
          concerned, it's not scrolling.
  esprehn: If it's not scrollable how did it get scroll intents.
  rbyers: By registering an apply scroll hook.
  smfr: It's like a wheel event handler.
  rbyers: It's similar but at a lower level.
  rbyers: Our next steps for scroll customization and compositor
          worker is to finish implementing scroll snap and position
  rbyers: We know there will be some overhead by using JS, but we
          should be able to compare with native implementation to
          gather any other numbers?
  rbyers: Anything else you would like to hear?

  esprehn: I'm interested in hearing your opinion smfr. You scroll
           in the ui process, right?
  smfr: Yes, this would involve going back to the renderer. It's no
        different that compositor worker. I'm not overjoyed about it.
  rbyers: Does it really have to be in the same process? It just has
          to be typically in sync.
  rbyers: You, e.g., control input on the ui thread.
  ojan: < shared a potential bubbling eg >
  rbyers: Since we have scroll latching on iOS, then we're only
          going to be scrolling a native or a custom scroller.
  ojan: Where do we chain today in chrome?
  ojan: If we don't bubble, why consume at all?
  rbyers: Some composition cases. eg, hidey bars. one impulse may
          scroll a bit and the leftover may need to be sent to the
          native scroller.

  esprehn: My question is that it feels like we need implementation
           experience. Our architecture is more amenable to this,
           but could we in 6 months, say, could he do an
  smfr: It's more than an afternoon and couldn't commit in 6 months.
  esprehn: The primary risk of this API that's ahead of its time
           that may be unimplementable in another UA.
  smfr: If we had to choose between this and compositor worker, we'd
        probably choose compositor worker.
  ojan: To judge the feasibility of our stuff, seeing CW would be
        very informative.
  rbyers: I guess we should just be explicit about a design that
          could work in all the engines. And we would definitely
          block based on your feedback if we needed changes to make
          it more implementable in your engine.
  rbyers: But generally our approach with this stuff is not to block
          progress on the absence of feedback.
  esprehn: AI: finish explainer to the point to where someone can
           implement it.
  rbyers: That's a spec?
  esprehn: No, just something less handwavy than what you've got.
  ojan: For interop, yeah, we need a spec. But for "could we ship
        something vaguely like this" we need rough feasibility only.
  esprehn: We need something where we can start to experiment. And
           the feedback we're getting is that compositor worker is
           the place to start.
  smfr: We're much more likely to implement the small declarative
        features that will fix existing content.

  RESOLVED: Flesh out the explainers for compositor worker.
            Experiment more and share data.

  rbyers: Separately. scroll chaining might be something we just do.
  rbyers: Let's bring it to csswg.
  esprehn Do you know what it is?
  smfr: Nope.
  rbyers: <shows the -ms-scroll-chaining property>
  ojan: <described how chrome latches on mobile since recently and
        how chrome plans to move desktop to latching>
  esphren: If everyone always implemented -ms-scroll-chain:none
           always, we wouldn't need the property.
  rbyers: Well, might be nice to have the ability to bubble if you
          wanted, but we removed it and no one complained.
  rbyers: The potential follow-up is that since this is potentially
          crazy for safari, if you can think of other ideas for
          stuff like rubber banding in a declarative way? A scroll
          delta transformation function, maybe?
  rbyers: This is a case that I'm less convinced that we need the
          power of script.
  rbyers: Maybe a couple of declarative properties and latching is
  ojan: I guess we're mostly done talking about scrolling.

  ojan: We may have beaten the topic to death, but I'd like to
        understand the performance concerns with running script
  rossen: We're always worried about folks writing slow code. This
          will always happen.
  rossen: But, assuming a middle ground where things are written
          "ok", the generic case.
  rossen: Yeah, I don't think I can bring anything new that I
          haven't said before.
  smfr: I'm more worried about the setup and teardown of global
        scopes than just the raw performance.
  smfr: And the security concerns.
  smfr: It couldn't fit in the UI process, so it couldn't be as fast.
  smfr: You can't have executable pages there.

  Scribe: rbyers

  vollick: But if it was async, you could post to another process
  smfr: But doesn't CW require it to be synchronous with scrolling?
  vollick: No, just best effort.
  ojan: I wonder if we could consider having more limited global
        scopes - could they be theoretically more efficient?
  vollick: Hopefully worklets wouldn't be coming and going very
  rossen: OK, we're done then.
  <gregwhitworth> https://github.com/w3c/css-houdini-drafts/issues/116
  <iank> https://drafts.css-houdini.org/worklets/.
  <zcorpan> iank: just filed
  <zcorpan> iank: i guess interface Worklet shouldn't have that,

Meeting Wrap-Up

  <Rossen> RESOLVED: Publish FPWD of Worklets Level 1
  <Rossen> RESOLVED: Publish FPWD of CSS Paint API Level 1

  <dbaron> We discussed next meeting, seemed to want to meet in May
           adjacent to CSS, and people seemed happy with May 12-13
           adjacent to CSS being May 9-11. And Google was going to
           look into Bay Area hosting

  Scribe: dbaron

  shane: On properties and values: dbaron convinced me about the
         special animation step not being needed. I had thought we'd
         need to alter the set of steps to run for resolving style
         would need to be altered, but one of those 2 things happens
         when triggering animation, not calculating current value,
         so there's no inconsistency.
  shane: The other thing is that animations and transitions already
         state that custom properties with a type should be
  shane: The only requirement is that the properties are of one of
         the animation types.
  dbaron: I think they should explicitly state that they have the
          animation type.
  shane: I hope for FPWD candidate by end of CSSWG meeting.

  <tantek> Thanks to Google for hosting!
Received on Sunday, 21 February 2016 20:06:46 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:57 UTC