[CSSWG] Minutes Tokyo F2F Wed 2017-04-19 Part I: Administrivia, UA-defined Variables, Animation Worklets

=========================================
   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