- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 26 May 2017 20:38:11 -0400
- To: "www-style@w3.org" <www-style@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.
=========================================
Minutes->GitHub Bot
-------------------
- dbaron wrote a bot that will automatically post minutes to Github issues
when the working group discusses them.
F2F Meeting Dates
-----------------
- The WG discussed meeting dates and locations, whether to have
3 or 4 meetings in 2018, and whether to peg one of those meetings
to the timing/location of the TYPO conference (April in Berlin).
Decisions were deferred until W3C Staff report back on the timing
of TPAC 2018.
UA-defined variables
--------------------
- dino proposed the ability to have UA defined variables for
things such as font size range which will allow developers to
act on them, though not change them.
- Tab pointed out that keywords can be used for such things
- Several people wanted to see constants instead of variables
- Further discussion will happen on GitHub
Add implementation status panels
--------------------------------
- RESOLVED: Add caniuse panels to CSS EDs to start
- Tab and plinss to improve liveness of data
- WG to discuss better ways to document and expose this info
both for us and for sites like caniuse and MDN
Reconciling web animations and animation worklets
-------------------------------------------------
- The breakout group came to a common understanding of how the
functionality should behave.
- The explainer document will be updated and another breakout will
be scheduled to plan the details on the API.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tokyo-2017#topics
Present:
Rachel Andrew, Invited Expert
Rossen Atanassov, Microsoft
Tab Atkins, Google
L. David Baron, Mozilla
Brian Birtles, Mozilla
Bogdan Brinza, Microsoft
Rick Byers, Google
Tantek Çelik, Mozilla
Emil A Eklund, Google
Elika Etemad, Invited Expert
Rob Flack, Google
Simon Fraser, Apple
David Grogan, Google
Dean Jackson, Apple
Ian Kilpatrick, Google
Vladimir Levantovsky, Monotype
Chris Lilley, W3C
Myles Maxfield, Apple
Jack Moffitt, Mozilla
Shinyu Murakami, Vivliostyle
Xidorn Quan, Mozilla
Florian Rivoal, Vivliostyle
Hiroshi Sakakibara, BPS
Simon Sapin, Mozilla
Alan Stearns, Adobe
Shane Stephens, Google
Surma, Google
Lea Verou, Invited Expert
Jet Villegas, Mozilla
Philip Walton, Apple
Scribe: iank
Minutes->GitHub Bot
-------------------
Rossen: Thanks for hosting us and the wonderful venue.
dbaron: I wrote a new irc bot, "minute-man". Its job is to comment
it github when we comment it github issues.
dbaron: "Github Topic: <github issue url>"
dbaron: Topic is concluded with new Github Topic line or Topic
line.
dbaron: It will log the resolution, and have an expanded irc log.
<astearns> an example of a bot comment: https://github.com/w3c/css-houdini-drafts/issues/393#issuecomment-294706386
dbaron: It will also remove the "agenda+" on the issue if it has write access.
astearns: I think we'll need to add the bot to the w3c github org.
<dbaron> minute-man, intro
<minute-man> My job is to leave comments in github when the group
discusses github issues and takes minutes in IRC.
<minute-man> I separate discussions by the "Topic:" lines, and I
know what github issues to use only by lines of the
form "GitHub topic: <url> | none".
<minute-man> I'm only allowed to comment on issues in the
repositories: dbaron/wgmeeting-github-ircbot w3c/
csswg-drafts w3c/fxtf-drafts w3c/css-houdini-drafts.
<minute-man> My source code is at https://github.com/dbaron/wgmeeting-github-ircbot
and I'm run by dbaron.
all: Much applause.
fantasai: Feature request: link to the irc logs within the github issue.
dbaron: Yes, need to refactor the bot to do that.
Rossen: Thanks dbaron, this is awesome.
Note: The bot was later renamed to github-bot
Resolve on dates for F2F meeting in SYD
---------------------------------------
Rossen: What are we thinking, there are 3 weeks proposed.
shane: I have a hold on all three weeks at the moment, outside
those weeks is going to be hard.
<eae> January 22 - January 25
<eae> January 29 - February 1
<eae> February 5 - February 9
Rossen: So, previously we've always picked the first week of feb,
or around that.
Rossen: What works best for people
<Florian> any of these three weeks is equally good for me.
dbaron: One thing we ran into before, the first week of school in
AU, flights were expensive around that time.
dino: 26th Jan is a holiday
shane: It's a Friday.
dino: That will be a long weekend.
dino: I think that is also school holidays there.
dino: The safest to avoid holidays is the Feb week.
<nainar> A quick flights search shows all flights to be equally
expensive. Though it is too early to estimate
shane: Term starts Jan 30th.
<smfr> australia school holidays
http://www.nswschoolholiday.com.au/index.php/nsw-school-holiday-dates-2017
Rossen: Feb 5-9 would that work?
Rossen: Lets agree on Feb 5-9, shane & dino unless we have more
info about school holidays
Rossen: It seems that back of the week has been working better.
fantasai: Last year we had a discussion about 3 vs. 4 meetings per year.
fantasai: If we want 3 we should resolve on that first, then resolve on dates.
astearns: We have Google for the first meetings, and then the next
proposal is April in Berlin near TYPO.
astearns: Whether we have 3/4 meetings next year we have 2 meeting
slots already.
dbaron: Jan/Apr are close.
Rossen: When is TPAC?
dbaron: 2nd week of November.
TabAtkins: Nov TPAC/Jan/Apr/ are too close together.
dbaron: The second meeting by April is too close.
TabAtkins: NovTPAC + EarlyJan is way too close.
TabAtkins: THINGS NEED TO MOVE.
Rossen: TYPO is set at the moment.
Vlad: It's going to be April but no firm dates yet.
Rossen: When is TPAC 2018?
Rossen: Is it going to be an early TPAC?
dbaron: I'm not aware of it being announced yet.
fantasai: Can we ping bert?
<tantek> TPAC 2017 is Nov 6-10 https://www.w3.org/wiki/TPAC/2017
Rossen: So, assuming that TPAC next year is going to be around
Nov... fantasai points out that we need to decide on 3
vs. 4 meetings, if we want to be near TYPO that places a
time constraint, Google hosting in SYD also places a time
constraint.
Rossen: April to TPAC Nov is 6 months.
fantasai: If we are limited to April + Nov, we need 4 meetings, or
have a 6 month gap.
shane: We could look at Google SYD hosting between Apr, and Nov
TPAC.
[shane & TabAtkins argue about relative niceness of summers.]
dbaron: Mozilla Toronto could be a good place as well.
Rossen: TPAC 2018 will probably be asia or EU.
fantasai: <draws a circular calendar on the whiteboard>
Rossen: We need to decide if we want to forfeit the early SYD
meeting.
Rossen: As TabAtkins pointed out there is a slow month between Nov
& Feb.
fantasai: I might get a lot done, on break then.
Rossen: Lets try and wrap up.
Rossen: At this point is the April meeting not an option to move
at this point?
Rossen: Can we move that meeting to Jun?
Rossen: I.e. Feb / Jun / Nov
fantasai: Do we want 3 vs. 4 meetings? If 3 we can't do April.
TabAtkins: Disagrees.
Rossen: Lets to a quick straw-poll
Rossen: Based on that we'll decide dates.
Straw Poll:
<fantasai> abstain
<TabAtkins> 3
<shane> 3
<eae> 3
<astearns> abstain
<Rossen> 4
<smfr> abstain
<rbyers> 3
<philipwalton> 3
<BogdanBrinza> 4
<Vlad> abstain
<Florian> 4
<dbaron> 3 (weakly)
<rachelandrew> 4
<tantek> 3 or 4
<xidorn> abstain
<iank> 3
<SimonSapin> abstain
<flackr> 3
<myles> 4
<koji> 3
<jack> 3
<birtles> 4
<TabAtkins> 3 weekly meeting for dbaron, check
<till> 3
<dgrogan> abstain
<astearns> average is 3.375
Rossen: So Google is pretty strongly in favor of 3.
Rossen: If we are going to stick we three. Jan/Feb is out of the
question.
eae: We can't really do Feb and Apr.
Rossen: This discussion is more for shane + google if hosting in
SYD.
fantasai: Do we peg to typo in April? If not we can do Google in
feb/mar, if we do one in (northern) hemisphere summer.
Rossen: I'm personally not aware of the TYPO constraint and being
close to it.
Vlad: The motivation that people may want to attend both (CSS &
TYPO) lots of people learning about CSS/TYPO.
Vlad: Good if CSS participants could attend TYPO.
astearns: I have a slight preference for TYPO and then a
(northern) hemisphere summer meeting.
Rossen: Ok if thats what we want to do, lets decide that and allow
shane to release hold of the rooms.
shane: Can we first make sure that everyone can make a timeslot there?
<myles> Vlad, where is typo?
<astearns> Berlin
fantasai: <please type your constraints in IRC>
dbaron: which months?
fantasai: Jun/Jul/Aug
fantasai: Maybe we pull all the constraints now, and decide
tomorrow
fantasai: after interrogating ChrisL
<dbaron> everybody from Mozilla likely has a problem with June
11-16, 2018
<shane> first two weeks of July are probably not good for Googlers
<rbyers> Google is out Jul 3 - 14
<plinss> first two weeks of June are problematic for me
<smfr> early june is often bad for apple folks
<shane> US summer holidays basically all of July and August?
<fantasai> yeah
<shane> plus late june if you're in high school
<Rossen> June is not good for Microsoft
iank: June looks out.
Rossen: So Jul/Aug? TPAC in Sept would be bad...
Rossen: Mid-Jul & Aug is what we are looking at in terms of dates.
Rossen: We'll figure out when TPAC is, then decide.
Rossen: Lets end with that.
ACTION: w3c staff please get back to us about TPAC 2018
Conditional Rules
-----------------
dbaron: I was hoping zcorpan would be here, but he's given
regrets. We should delay or take it offline.
dbaron: Who was driving the issue?
Rossen: It came from the driving specs to REC. You said we need to
resolve some things with zcorpan.
dbaron: Push it offline.
UA-defined variables
--------------------
Scribe: ChrisL
dino: Want to expose values that are UA specific, like the range
of text sizes for accessibility.
dino: Nice to expose them as variables, but the user can't change
them, can only use them.
dino: No concrete proposal or list.
iank: --safari-- stuff?
dino: No.
tabAtkins: A user-agent variable is otherwise known as a keyword
in CSS
dino: Variables is a nice way to expose them.
TabAtkins: Can be used anywhere which is nice.
shane: Want to see a const construct, users often have const
variables too.
dino: Conflicts with const in JS.
shane: Seeing people in the wild use a ton of variables.
TabAtkins: Special case vars defined on the root.
Rossen: Seen people want that for colors, fonts.
dino: scroll-bar width.
TabAtkins: UAs can insert this.
eae: Expose ui value keywords such as selectioncolor or default
fonts as well.
leaverou: Existing fallback mechanism on vars would help here.
TabAtkins: Use a normal keyword for the ua defined ones.
TabAtkins: Keep variables for users.
dino: Don't want vendor specific ones.
<Florian> ---
<fantasai> -
<TabAtkins> (--- is a valid var, try again)
<fantasai> -foo
<Florian> two em-dashes
<fantasai> ascii!!
<shane> ~~foo
<TabAtkins> (We promised to keep CSS syntax within ASCII.)
leaverou: Benefit of variables over keywords?
TabAtkins: Messes with the grammar if they are allowed literally
anywhere. eg in calc.
Florian: Var like things but not keywords.
<Florian> or units
dino: If they are -- it gives authors a way to provide default
values.
astearns: Especially for UAs that don't support it yet.
<TabAtkins> `--foo: whatever !const;` <== only allow on a root
element (document or shadow tree)?
Florian: Parsing of var function, can we define ones without --
but for legacy reasons no.
dino: @supports can't be used with variables
dbaron: Can use @supports display: var(foo)
dino: Like to keep the var function and not require the dashes.
shane: And allow them to be marked as const.
iank: A non changing variable.
shane: 100+ const-like variables in many stylesheets. If const
would be a lot cheaper.
dino: Okay, but need a syntax proposal.
dino: You special-case root?
shane: As a cache, only. they can still change.
TabAtkins: Anything starting with a ! is open, we could use that.
TabAtkins: vars are syntax checked so can set a custom property
and give it the value of the var kw which will syntax
fail on...
<TabAtkins> --foo: my-fallback; --foo: var(UA-keyword);
TabAtkins: second one fails at parse time
TabAtkins: so usual fallback mechanism.
<Florian> should probably do "--foo: my-fallback; --foo: var
(UA-keyword, my-fallback);"
xidorn: Why does the second one fail?
TabAtkins: Should invalidate the property at parse time.
Florian: Also fallback inside the var function.
dino: I will open a GH issue to bikeshed the syntax.
<TabAtkins> (Expanded explanation: syntax is `var( <custom-property-name> )`,
where <custom-property-name> is a --name. Thus, per spec,
using a non-dashed keyword is syntactically invalid
and should be rejected at parse time.)
Add CanIUse panels
------------------
<dbaron> Github topic: https://github.com/w3c/csswg-drafts/issues/1219
fantasai: We were asked to add these to our specs.
fantasai: Was filed as an issue on individual specs, but we should either
do it on all or on none.
Florian: Seems useful.
fantasai: Main reason not to is that it is unofficial.
leaverou: Better than nothing and they use tests.
Florian: editors drafts or TR?
ChrisL: There was this thing about using scripts on our own site
[ChrisL talks about w3c publishing policy]
TabAtkins: It's just the images that aren't local.
ChrisL: It's a static snapshot?
TabAtkins: Based on current state of database when you generate it.
ChrisL: Then it needs to be very careful to be labeled as such.
<tantek> Do any other specs on /TR have it?
leaverou: Could we make it live?
TabAtkins: But then you have more live dependencies.
TabAtkins: I don't like having lots of live dependencies.
ChrisL: We have live dependencies for tests, it's great.
leaverou: It's extremely misleading for ppl to make it static,
especially because we take years to publish a new spec.
TabAtkins: Which is a reason to keep it for EDs only.
tantek: What's being asked for?
Florian: Our specs don't have it, others do.
tantek: whatwg uses them.
tantek: Do any specs on /TR have this now?
tantek: No one else at w3c has done this, is that a blocker?
fantasai: Want us to have an updated /TR rather than ED and what
has stopped us in the past is the process of publishing.
fantasai: Now we have echidna, no reason why an editor can't get a
resolution and push to /TR for every significant update.
tantek: Lots of reasons why that doesn't happen.
fantasai: Once it is resolved no reason not to push to /TR.. want
/TR to be as useful as ED so ED can be the scratch space
rather than official reference.
tantek: Agree but out of scope for this issue.
fantasai: Having useful stuff in ED and not TR means /TR will be
a second-class citizen even if we keep it up to date.
tantek: Way out of scope.
tantek: Blocking on this is not reasonable.
leaverou: If we add them on ED then we should add on TR as well
and live, not stale.
fantasai: Even ED can go for a time without being updated, like
scroll snap where there are no edits but impl data
updates.
plinss: (explains multiple pass database regeneration)
plinss: (EDs get regenerated frequently even if not edited)
astearns: Want these to be in /TR and as that is not regenerated
we need it to be live. Tab can we do that?
TabAtkins: Annoying duplicate paths but can do.
astearns: Updated from spec.
leaverou: How about bikeshed does it and then a script updates.
TabAtkins: Sure.
TabAtkins: plinss will write it.
leaverou: What about features behind a flag hides vendor interest?
TabAtkins: Decided that behind a prefix is hidden because wanting
to see what can be used. Explaining what is available
with what prefixes is ....
rbyers: canisue can be updated very slowly
rachelandrew: caniuse often out of date.
Rossen: Microsoft updates MDN.
till: Mozilla could make an API to get that data easily from MDN.
Scribe: fantasai
rbyers: MDN doesn't have a nice API like caniuse does.
rbyers: We've talked with MDN folks about that before
rbyers: For case of developers, they're already going to caniuse.
till: If that's what it takes to get us all to agree on updating
this data, then it's a strong reason to do this.
Florian: There's also no reason for caniuse to not use that data,
if it's available through an API.
leaverou: Even if purpose is not for implementor interest, but for
developers.
leaverou: But it makes a difference between not implemented at all
maybe not arriving, or whether it's implemented behind a
flag and coming up.
leaverou: Recently I solved an issue in images 4 where there was a
table, everything was gray, no implementations.
leaverou: I clicked through the caniuse link, and it was a wall of
green. Why trust the tables if discrepancy is so big.
TabAtkins: No guarantee that stuff behind flag or prefix is
anything similar to what's in the spec.
rachelandrew: We need to expose things behind a flag so we can get
feedback from developers.
Florian: Can we sort of resolve on this and file bugs on Tab and
Peter or?
eae: It's only really useful if there's a reasonable expectation
that it's at least somewhat recent or up to date.
rbyers: Devs find caniuse very useful even though not up to date.
Florian: But it's not 3-4 years out of date.
rbyers: If what you really want is behind a flag use case, the
only way to get that is an automated system.
rbyers: We're going to make a tool available later, called API
Confluence Dashboard, similar to Edge API Catalog, but
it's an automated tool that lists all of the APIs
available in every browser and how they've changed over
time.
rbyers: This is further out, but if we want to tackle what things
are under development, this might be more practical way to
tackle long term. It'll always be fresh.
smfr: Generated by software?
rbyers: Yes, used by walking the object graph.
rbyers: Doesn't work for all kinds of features, but some things.
rbyers: Depends on browser being available on browser stack.
ChrisL: Safari Tech Preview, I was using it in browser stack
yesterday.
fantasai: Sounds like we have lots of ideas but haven't documented
how/where to do it.
rbyers: Maybe 2 outcomes from this, use Tab's caniuse for now.
rbyers: And have a small group to discuss making better.
tantek: Yeah, have something that works today, let's go with that,
experiment on ED
tantek: and then solve in /TR later.
eae: Risk of bad data being propagated.
tantek: Yeah, so try out on EDs.
tantek: Don't wait for perfect being enemy of the good.
fantasai: So, plan is enable caniuse panels on EDs, and
investigate better ways of exposing data and putting on
/TR.
RESOLVED: Add caniuse panels to CSS EDs
Rossen: Further fallout is to discuss better ways of exposing the data
Rossen: in useful and more predictable ways.
Rossen: Don't have to decide on this now.
fantasai: People who are interested in figuring out how to collect/
expose data should have a side discussion.
tantek: Drop it into a github issue?
fantasai: Sure, side discussion while we're here, but keep things
someplace where others can participate.
<br type=coffee>
=== Breakout Session ===
At this point part of the group moved to speak on animation topics
(below) while the rest stayed to continue the regular agenda
(Wednesday Part II)
Scribe: iank
Reconciling web animations and animation worklets
-------------------------------------------------
flackr: So in the previous session, we thought that
animation-worklet felt like an effect, lots of
inconsistencies, subclassing animation a more natural fit.
Can choose timelines, elements, etc.
flackr: We'd be happy to go with this as the only way to construct
it now.
<astearns> https://gist.github.com/majido/7e542e5af9ef090ba0ab7584316f235d#file-aw-ideas-js
flackr: <explains the above example>
birtles: It's a small thing but the timing stuff goes with the
effect.
majidvp: But as we talked it makes sense for these to be animation
as timelines.
birtles: Can we do effects initially?
birtles: And then we might allow you to do other effects later
birtles: (can we make this look like the web animations initially).
iank: birtles is main concern lack of effects?
birtles: Doesn't have a lot of correspondence, you can pass in
timelines, but that is about it.
birtles: Trying to get it to feel like one platform.
surma: I always thought that web animations can be built on AW.
birtles: My feedback from yesterday it feels quite separate from
web animations.
flackr: What if you pass the animation worklet a list of effects?
iank: What do we loose?
flackr: If you were driving a transform, drive the axis separately.
iank: Pass in two effects.
shane: Lose main thread niceness, gain worklet generality.
majidvp: How would you deal with multiple timelines.
iank: <describes how this could work with effects>
flackr: This is missing input properties; which we had in
animation worklet.
birtles: Is that guaranteed to be constant?
iank: <explains the inputProperties map in the previous example>
birtles: I was just concerned that if you could feed in an
animated property, you may have to throw back to the main
thread.
birtles: The thing that might be awkward with keyframes, if you
want to achieve the drag-and-drop effect, might be hard?
flackr: You'd have a KeyframeEffect that would go from [0->1000px]
flackr: This doesn't keep the animation & animator-root
iank: <ian explains problem with not being able to dynamically
pass in additional keyframes initially>
flackr: If you can update the effect list, and update the extra
data, then this solves the use-case.
iank: Its kinda nice to have this hooked up to style.
majidvp: You could construct keyframes in the animation worklet.
majidvp: What if I get a keyframe which isn't bound to an element,
majidvp: and then bind it to an element later on...?
iank: <thinks...>
iank: Problem with replacing effect, is that could be pulled to
main thread at any time, would have to have the onDestroyed
callback to stash the state for a later frame.
flackr: animation-worklet described as set of data, and timelines
to drive the list of effects.
Scribe: rbyers
birtles: How much of the regular animation effect can you
implement this?
<iank> https://gist.github.com/bfgeek/a489f6e59c1282bbde1e9c0123f14d1c
iank: Complexities around reverse and playback rate, you could
imagine them as additional input to animation function.
iank: Animation function gets list of timelines, list of effects,
bool that indicates whether in reverse.
flackr: Why not just have a function on the animator that gets
called on reverse?
iank: That's fine too.
birtles: Passing in params encourages authors to think about.
majidvp: But can't guarantee not having any state in animator, so
what does it mean to reverse? Not necessarily a pure
function.
flackr: We could require that you define a reverse function, just
like we require you to define an animate function.
birtles: There's reverse, pause, finish, playbackRate, setting the
current time.
iank: Most of these are easy.
iank: Cancel would nuke.
rbyers: Pause would just not call animate.
birtles: Ideally for every worklet you don't have to define 6
methods, nice to have a default.
flackr: Yes most can have reasonable default.
iank: For cancel play pause finish you don't actually want the
animator to customize. Would you ever want non-default?
birtles: Maybe.
birtles: For finish depends on what you're animating
birtles: finish takes you to the end, cancel removes.
birtles: Meaning depends on what you're animating.
shane: Different way of thinking about this. All of our modeling
so far has been about a single timeline
shane: so we made these about the animation
shane: but maybe they're really about the timeline,
flackr: What's the end of a document timeline?
shane: When timeline is infinite, animation bounds influence on
the timeline
shane: not sure this works, but worth exploring.
birtles: Thinking about the whole worklet animation concept
birtles: synchronization between main thread and compositor
birtles: in Gecko we go only one direction - main to compositor,
never sync back
birtles: how would that work here?
flackr: In Chrome we do that with scrolling
flacker: eg. handling scrolling in the compositor then sync scroll
position back to the main frame.
majidvp: Instead of running animation in two places, we run in the
worklet then sync them back.
birtles: May work with scroll - we can use any old value. But for
timing may not work - main thread time is fixed, can't
get old time.
birtles: Can it temporarily jump backwards and forward again?
flackr: You're never getting a historical value - get the current
value at the beginning of the next frame.
birtles: eg. start a new frame now on the main thread. before
style resolution, compositor ticks and updates it's
result.
birtles: ...
flackr: We were proposing that you'd get the value that was
generated for the previous frame.
birtles: Doesn't that mean it's out of sync with other animations?
flackr: Yes.
majidvp: That's the whole idea - async.
flackr: Similar to scrolling being out-of-sync between compositor
and main thread view.
dino: So if main thread asks compositor for current state, always
getting a frame behind
dino: which frame does main get back?
iank: At rAF time, last possible time to sync.
flackr: When delivering rAF, send from compositor last values
flackr: before invoking rAF get values from compositor.
rbyers: There's some open interop issues here on the platform -
whole rendering pipeline debate at houdini a year ago.
iank: When compositor tells main thread it should start its next
frame, send over the state for that frame.
dino: compositor may have rendered stuff by then
dino: so may be a frame out.
iank: Yes, but if you really want sync then you could have an
option to pull the animation to frame.
rbyers: This makes sense because we're trying to explain how
threaded scrolling works, and all browsers (except for
special chrome sync scroll case that doesn't really work
reliably) have this latency today.
dino: So your compositor drives the rAF signal?
rbyers: Yes, yours doesn't?
smfr: No, we have no idea when things go to the screen that's up
to the OS.
birtles: Ours doesn't either.
flackr: Anytime the worklet produces a frame, gets send to main
and used in next rAF.
majidvp: May run multiple frames if main thread is busy, may tick
in the mean time
majidvp: but at some point it'll send an update that's used before
the next rAF.
iank: We won't be running worklets on the compositor thread, on
another thread that tries to keep in sync.
dino: Compositor tells main thread and worklet thread what the
values are?
flackr: No, worklet generates values and sends those to the
compositor, compositor includes in current frame and syncs
back to main.
rbyers: And what about scroll position, how does it get the
current scroll position?
flackr: Compositor sends it to worklet when it needs a new
animation.
smfr: Where does the rAF timestamp come from.
flackr: Beginning of current vsync.
smfr: When compositor sends rAF signal to main thread, does it
snapshot timestamp and send it?
flackr: Yes.
flackr: Whatever is driving rAF should indicate the timestamp.
smfr: You were saying main thread can be a frame behind but you're
saying the same timestamp is used?
smfr: oh but worklet stuff may show up first.
majidvp: Yes.
surma: You said worklet can draw multiple frames when main thread
busy. should we spec that latest values are what always
show up on the main thread?
flackr: I don't think we should, just spec as best effort. Risk of
not getting data back to the main thread in time, don't
want to delay.
surma: ok
surma: Can't enforce any guarantees here.
iank: We want implementations to be able to run whatever
properties on whatever thread.
dino: In the example, how does the scrolling timeline work?
majidvp: We took this from scroll linked animations spec.
majidvp: Scrolltimeline has a source element, time range and start
and end offset.
majidvp: Offsets are by default whole scroll range,
majidvp: maps scroll range onto the time range,
majidvp: by default takes animation duration to be time range.
dino: If you want to move something in the worklet that's pixel by
pixel you need to know how big the scroller is... and if it
changes size?
majidvp: Yeah exactly, this seems problematic.
birtles: Yeah I'm not thrilled with the spec here, ok with
changing this - even if it means scrolling the actual
scroll offset.
birtles: I could use some help fixing the spec
majidvp: Driving something according to scroll position is common
pattern, converting through times seems like a hack.
flackr: Could we add source scroll offset to the scroll timeline
spec?
birtles: Absolutely, spec is just to get discussion going.
birtles: Already talked about whether we can do something for
transitions in that spec.
birtles: Can't do hidey bars, need to fix that.
flackr: Sounds like we could come up with something to avoid
passing in the scroll ranges.
rbyers: We definitely don't want to try to shoehorn everything
into the concept of time.
majidvp: We want some way to know when a scroll gesture ended.
rbyers: Could that be a timeline that gets to a finished state?
birtles: Yeah or some sort of inactive state where it produces
null.
rbyers: Where did we land on animation vs. effect?
majidvp: We have an animation that receives effects (instead of
elements).
birtles: Gives the browser some idea the range of values it'll get.
majidvp: Does limit some cases - eg. expando.
flackr: You can have a custom timing function.
birtles: Maybe worth doing custom timing functions separately.
Could be called from the worklet.
shane: With stateless timing functions you can memorize them
(serious of linear segments), never need to do off thread
javascript for them.
iank: Just interpolation.
iank: But separate discussion, agree that we can add them.
birtles: Doesn't need to be a core use case for this, should be
separate.
birtles: There's a few things we need to add to web animations,
like pass in a time value and get the result out.
majidvp: Can't evaluate a KeyframeEffect.
majidvp: We want Animation as base class.
birtles: We've only shipped Animation, not Effect or Timeline.
iank: So we could add an AnimationBase?
birtles: Yes, if we need do.
majidvp: What about timeline? Assumption now is there's only a
single one.
flackr: This is a different kind of animation, ok to have
different rules.
flackr: Default timeline concept is nice, if we want to go with
reversing/pausing we'd know which one we're talking about.
shane: Might make sense for reverse and cancel apply to all
timelines at once.
shane: Cancel is obvious, want to remove all
shane: but finish?
shane: Imagine translating x and y to match finger position.
shane: Finish moves to bottom right.
shane: Reverse makes it so when finger does down and right,
translation is up and left.
flackr: playbackRate would be weird.
birtles: just a multiplier
birtles: so a little scroll would take you further.
flackr: Concern is that if you change playbackRate party way
through have a discontinuity.
birtles: I think we implemented this and did discover that.
flackr: Might be better to just make it a parameter the animator
can access.
birtles: Does a seek afterwards.
shane: playbackRate changes the domain as well.
iank: playbackRate and reverse as parameters probably makes the
most sense.
flackr: Is it up to the animation to decide how playbackRate
affects the effects?
smfr: If you have multiple timeline inputs may just want to scale
one not both.
majidvp: May want a default behavior for reverse but could
customize it.
majidvp: Animators may be stateful, reversing timeline may not be
enough.
flackr: Could have default behavior which reverses your timelines
but override to do something else.
majidvp: Have you (Brian) thought at all about scroll linked
animations will related to grouped effects from level 2?
birtles: Effects aren't scroll or time-based in particular.
There's a hierarchy with a single root, that's where you
get your progress source (time or scroll) from.
majidvp: Can't have a group with two different timelines
birtles: Right, but here you could
birtles: only AW.
flackr: OK what are next steps?
rbyers: Update explainer and get Brian (and others) feed back on
it.
iank: Then flesh out the details.
birtles: On Friday we have scroll-linked animations, but don't
have anything in particular.
birtles: Should we defer until after?
flackr: I've looked over the spec.
iank: We could do a breakout tomorrow to flesh out the API.
rbyers: OK majid and flackr will work on a new explainer now,
share by end of day. Then breakout sometime tomorrow to
cover both scroll-linked animations and update here.
Received on Saturday, 27 May 2017 00:39:01 UTC