- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 23 Mar 2016 20:00:19 -0400
- 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