- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 2 Jan 2015 09:56:22 -0500
- 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.
===== FULL MINUTES BELOW ======
Scribe: dael
Animations
==========
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 ->
animation-combine
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
additive?
dino: Yes. Web animations has done a good job of that. Most aren't
additive.
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
conflicts.
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
end.
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
doesn't.
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
visual.
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
animation.
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
recorded?
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
disconnect?
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
disappearing.
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
off.
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
effect.
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
reappear.
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
snap.
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
customization.
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
it?
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
exposed.
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:
https://docs.google.com/a/chromium.org/document/d/1aOQRw76C0enLBd0mCG_-IM6bso7DxXwvqTiRWgNdTn8/edit
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
smoothly]
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
properties.
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
screen.
volick: Of course, this does give the possibility of people doing
badly.
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
set.
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
hard.
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
solution...
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
them.
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,
etc.
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
sync.
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
font-size.
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
this.
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:
https://docs.google.com/a/chromium.org/document/d/1oEVWIVdMZ2OlVZMvcZZ3IgaT6RAUNSKAzpzb9AlVeLw/edit#heading=h.kd0gtwwz5bf9
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
architecture.
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
intention.
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
scroll.
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
developer.
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.
Agenda
======
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
out.
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