W3C home > Mailing lists > Public > public-houdini@w3.org > April 2018

[Houdini] Minutes Berlin F2F 2018-04-09 Part III: Custom Paint, Animation Worklets, Paint API, Typed OM, Worklets

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 25 Apr 2018 20:28:31 -0400
Message-ID: <CADhPm3vUDCQtvTKgX+ar7+bjrjoVZ-jW28hLzOEx-U7aWPy4Mg@mail.gmail.com>
To: public-houdini@w3.org
Cc: CSS WG <w3c-css-wg@w3.org>
=================================================
   These are the official Houdini Task Force
     minutes. Unless you're correcting the
      minutes, please respond by starting
 a new thread with an appropriate subject line.
=================================================


Custom Paint
------------

  - RESOLVED: Keep the spec as is. (Issue #729: ident vs. custom ident)
  - RESOLVED: Keep the current design. (Issue #564: JS export vs.
              registerBlah)
  - RESOLVED: Drop section 2: paint invalidation. (Issue #447: Make
              paint invalidation non-normative or something?)
  - RESOLVED: Keep the design as-is for the callback interface. (Issue
              #743: callback interface vs. not)
  - RESOLVED: Conform to webIDL callbacks in the spec.

Animation Worklets
------------------

  - RESOLVED: Not have a dynamic ability on animations, they're either
              stateful or not. (WICG Issue #87: Improve potential for
              generating multiple animation frames in parallel)
  - RESOLVED: Introduce 2 classes as a mean to listing stateful and
              stateless types. (WICG Issue #87: Improve potential for
              generating multiple animation frames in parallel)
  - RESOLVED: Move the spec from WICG to CSS Houdini drafts (as an ED).
  - RESOLVED: Short name is 'CSS Animation Worklet' (may decide to
              revisit this when doing FPWD).

Paint API
---------

  - RESOLVED: Paint function and custom paint function registration
              does not change. (Issue #751: Rename paint(name, args)
              to paint-name(args))

Publication
-----------

  - There's already an outstanding resolution to publish Layout API so
      no new resolution is needed.
  - RESOLVED: New WD for Painting API
  - RESOLVED: Publish new WD of Typed OM
  - RESOLVED: Publish a new WD of Worklets L1

===== FULL MINUTES BELOW ======

Agenda: https://github.com/w3c/css-houdini-drafts/wiki/Berlin-F2F-April-2018

Scribe: dael

Custom Paint
============

ident vs. custom ident
----------------------
  github: https://github.com/w3c/css-houdini-drafts/issues/729

  iank: Currently it's spec as an ident. Except css-wide keywords like
        inherit.
  TabAtkins: We said ident so we don't collide. Since this will always
             be in a function there's no collision so no reason to
             exclude unless style reasons.
  iank: I don't think there's any reason not to.

  leaverou: I opened an issue 20 minutes ago to say it was more
            readable if the ident was moved to the function name, so
            that instead of paint(foo, ...) it would be
            paint-foo(...). Does this interfere with that?
  iank: No.

  iank: Objections to keeping it as an ident?
  Rossen: The person filing the issue was not here?
  TabAtkins: Yes.
  Rossen: Just curious if they have really strong opinions.
  fantasai: If you start disallowing and then allow nothing will break.
  TabAtkins: I doubt if it'll break. 'default' is the only one that
             could be useful.

  Rossen: Objections to keeping it as is?
  emilio: No but I wouldn't object to changing either. It seems
          harmless.
  ChrisL: It's not ambiguous, but it's unclear. There's tests failing
          in fonts with initial. I'm mildly in favor of the proposal.
  gsnedders: I'm also mildly in favor.
  Rossen: How mild? If you object let's discuss.
  gsnedders: I don't care.

  RESOLVED: Keep the spec as is.

JS export vs. registerBlah
--------------------------
  github: https://github.com/w3c/css-houdini-drafts/issues/564

  iank: You can export things from a module. Should the engine be
        smart enough to crawl the export and pick off things that use
        paint.
  iank: Should we allow this in the spec?
  surma: My reason was you can build that on the API we exposed.
  surma: This seems more dev convenient, but I'm not sure how much
         they would experience the convenience since everyone is
         bundling.
  surma: I think this is nice, but not worth the effort.
  iank: I think it's a bit of work for us. We don't have the
        information immediately exposed.
  surma: Any assumption that you can dynamically import and then try
         and do exports, but if we don't have that you can't do it.

  iank: Do you think web dev coming to these APIs would expect...this
        is the first time an export could register
  surma: We have used them, like the register call, which is not what
         I've seen in other APIs.
  dbaron: This may depend on how people perceive using them a couple
          years down the road. People who follow ECMAScript closely
          may have a better sense.
  fremy: You are supposed to be using import/export if you use
         modules, but I don't think there's an impression that the
         browser is pulling by default. I thought it was cool but if I
         have to write the function I'm not here.
  majidvp: If you switch to exporting you don't know if it's paint or
           layout until you use module. But not when you register you
           register for a thing so you can verify.
  iank: Good point. Some of the custom paint scripts we've seen people
        using it in the main window and the worklet. You can catch
        exceptions of registerPaint.
  majidvp: Can you throw exception when you export?
  iank: You can throw a global.
  dbaron: Also you can search for the registerPaint name to find out
          what it does. If it's export syntax I'm not sure how easy.

  plinss: If we allow export we have to add more clarity. You need
          another class to indicate this is a worklet. A bare export
          is really dangerous with extensible concerns.
  iank: It seems like an idea we'll keep for later if this becomes
        common.
  Rossen: Sure.
  flackr: Other way is at the point you add a module, naming the
          things you expect to be exported.
  Rossen: Objections to keeping the current design?

  RESOLVED: Keep the current design.

Make paint invalidation non-normative or something?
---------------------------------------------------
  github: https://github.com/w3c/css-houdini-drafts/issues/447

  iank: Pointed out by Alan Jeffrey that...basically we have a section
        of the paint spec that says how invalidation works.
  iank: If you have a paint validation and the style changes you have
        to make changes and you invalidate. It was pointed out you
        don't need that because you have the caching function. The
        caching is all the input are the same. So we could drop the
        whole paint invalidation section and rely on the caching and
        that engines can be cleverer.
  iank: Thoughts?
  iank: We could make this non-normative and say you can do validation
        this was or rely on caching step.

  dbaron: I have a vague memory when I looked awhile ago I thought
          this section was more complex then it needed to be.
  iank: Maybe. I think I changed it since then where we moved the
        invalidation to individual paint functions. [reads] "At this
        stage the user agent may re-use an image from a previous
        invocation if paintSize, styleMap, inputArguments are
        equivalent to that previous invocation. If so let the image
        output be that cached image and abort all these steps."
  iank: We could drop this and let the engines do smarter. Or make the
        whole section non-normative saying that engines can add
        invalidation.
  shane: It would be much faster [missed]

  Rossen: Leaning toward making it non-normative?
  iank: I'm fine with that. I think it should still be in the spec
        because I think engines will do that.
  krit: Is there something we should add to ensure that everything is
        correct?
  iank: We did that.
  smfr: The invalidation isn't exposed.
  iank: Yeah.
  iank: As a webkit engine impl your thoughts?
  smfr: I don't think there's value to this section. Is there other
        text that spec when something becomes invalid?
  iank: No
  smfr: You need that. You need to describe inputs that trigger.
  iank: We've got that in the cache step. The paint size and similar.
  Rossen: Objections to dropping section 2: paint invalidation?

  RESOLVED: Drop section 2: paint invalidation

callback interface vs. not
--------------------------
  github: https://github.com/w3c/css-houdini-drafts/issues/743

  iank: We built to be consistent with custom elements API when you
        register paint or custom element we'll callback to anything
        that exists and then not touch it again.  We did it to be
        consistent with custom elements.
  iank: Other then the APIs which always look up function before you
        invoke it....our version is strict that's slightly more
        relaxed. There's small stuff that needs to go in, but it's a
        question of if we should use callback effects.
  iank: I prefer the system we've got for consistency and it's
        slightly faster.

  majidvp: One of the problems with current spec you use the functions
           but it's the webIDL pattern.
  iank: We need to change them to webIDL format. We need to change the
        existing stuff to webIDL callback, but not a full callback
        interface.
  majidvp: Can you make a callback interface?
  iank: Yes.
  majidvp: I remember some warning in webIDL that you can't construct
           one.
  iank: There's now a section in webIDL spec [looks for it]
  majidvp: A callback function can be a callback interface?
  iank: No, it can be literally the function passed into it. We're
        expecting a function to be passed into webIDL. Main thing is
        going through and making sure incumbent realm is correct.
  iank: It's fine if we go with that. Callback interface vs not is the
        question.
  iank: I'd prefer as-is to be consistent with custom elements.
  iank: Unless there's a really good reason why we shouldn't.

  iank: Here I think sticking with what we have may be a performance
        hit based on how many times we're invoking the function.
  iank: I'd prefer to keep as is.
  TabAtkins: I'd prefer caching.
  iank: We can also, assuming we code....you can wrap the behavior as
        well.

  brian: Can you re-register?
  iank: You can't re-register but you can wrap it up and re-call it.
  Rossen: Anyone think we should not keep the current design?
  iank: We'll need to make some small changes to align.
  Rossen: Objections to keep the design as-is?
  iank: Do we need to resolve to make changes to use webIDL?

  RESOLVED: Keep the design as-is
  RESOLVED: Conform to webIDL callbacks in the spec

  iank: I think that's all I have on Paint
  Rossen: That's all that was on the wiki

  Topic: break

Animation Worklets
==================

Improve potential for generating multiple animation frames in parallel
----------------------------------------------------------------------
  Github: https://github.com/WICG/animation-worklet/issues/87

  majidvp: Right now when you have an animation worklet everything you
           register is considered stateful. Some of the effects you
           don't need to have local state. If your animation doesn't
           need local state it's good to know.
  majidvp: When it's stateful you need to go in sequence.
  majidvp: Ask was to be able to make the distinction explicit.
  majidvp: Proposal from Alan was to have a state object. This is
           similar to layout API and caching property.
  majidvp: Proposal is to have a state object on the animation which
           the impl uses to 1) if the state object is available it
           means it's stateful and not a pure animation and 2)
           previously we had an onDestroy callback which allowed the
           animation to serialize. This proposal allows us to get rid
           of that callback. We can just serialize the state and move
           it when going between.

  smfr: Seems odd to have the state...Once you computed the state the
        first time you might want it to be read only.
  flackr: If you want that you should pass that in rather then
          computing it. It's a static input.
  shane: Is that too restrictive?
  flackr: Maybe? If you had a state that didn't change regularly you
          could imagine allowing parallel execution until state
          changes. I don't know if that's a common use case.
  majidvp: If you have a state it means we opt you out of run in
           parallel. Could be possible we have a state and until it
           changes you're in parallel. Let's be more conservative and
           if there are use cases we can relax.
  flackr: Only concern with relaxing is detecting the state change.
          You have to detect or have an API to say I changed.
  majidvp: Initial version was to have a state boolean which would
           indicate if it allows parallel execution. We can do
           something like that in the future with the boolean.

  smfr: isStateful is a better description the hasState
  majidvp: Current proposal is if the state object exists it means
           it's stateful, not use isSateful or hasState.
  smfr: Can you show us the API?
  majidvp: First argument to the constructor.
  majidvp: It would make sure that if you have an actual state you set
           it on the state object so when you move between global
           context you keep your state. If we kill your instance your
           state sticks.
  majidvp: You can hold onto your state.

  birtles: You look at length of constructor function?
  majidvp: Every time we animate you we call the state getter. If that
           provides an object that's your state and it means you're
           stateful. Every time we destroy the global scope that state
           will be passed in to you.
  majidvp: It's only when you register the animation. First time
           you're called it's null, as we animate you can change.
  birtles: If you're looking at length of constructor I understand
           that, but how do you know.
  majidvp: You're looking at spec, this is a proposal. You get the
           state and the options.
  birtles: The difference between an animator and a pure animator is
           clear to anyone that works in ReactJS.
  shane: It's an import and distinction too.
  shane: Maybe an flag is acceptable.

  majidvp: One thing about taking this flag is it can change over
           time. You start as stateless and at some point you do have
           a state from that point on you're stable.
  shane: Can you clear state?
  majidvp: Yes.
  shane: This would be useful with impl a state machine. You can make
         a decision about what the next animation is.
  birtles: What if you have several frames at once and one is stable.
  shane: You're stateless if it's many frames. If one frame is
         stateful it stops there.
  majidvp: The example from Jan. they run in parallel and if they see
           state they can't treat it the same.
  birtles: They're saying it's not implementable. You're either
           stateful or stateless, choose one.
  majidvp: Personally I'm fine for it to be static. Most of the use
           cases weren't specifically stateful or stateless, but it
           did change.
  flackr: Let's say we go with something static now, how may it change?
  shane: If you register yourself as stateful or stateless you can
         register yourself as auto and change.
  flackr: Right thing to do is static route until we have feedback.

  majidvp: iStateful is the proposed name?
  smfr: Yeah.
  shane: Do we want State or Stateful?
  majidvp: It would be a static property on the animator class.
  shane: It should be enum values so it's extensible.

  birtles: In the current spec you ask to register a function and that
           will change you pass something else?
  majidvp: It's a function callback. It's a class similar to Paint.
           This is a class that implements callback interface. In the
           class there's a static property of isStateless
  birtles: I'm wondering if we can just look at functions.
  majidvp: My understanding is that there is slightly different syntax
           for stateful and stateless. If you're stateful component
           it's a class.
  majidvp: I think in this case static attribute on the class seems
           usable enough.
  shane: Makes it explicit.
  majidvp: There's nothing like this on other spec where we can extend.

  Rossen: What did we narrow down to?
  Rossen: Do we keep going with isStateful?
  majidvp: I think it was have explicit attribute on the class, I
           don't know what the name should be. If you want an enum
           stateful isn't a good name.
  majidvp: An enum is the right idea, I'll bikeshed the name on the
           issue.
  Rossen: We want to have the state state on the class, name pending
          bikeshed.
  Rossen: Objections?
  birtles: I'd like to look at other options. I'm not 100% sure we
           need the attribute.
  shane: If we want to preserve possibility of switching we need it.
  birtles: I think there's more inquiry to do.

  Rossen: Before we resolve on the big issue, we can resolve on having
          the state always be one by construction. Either always
          stateful or not.
  Rossen: For now we're not allowing a dynamic state. Let's resolve on
          that and then figure out if we need to expose it.
  Rossen: Objections to not having a dynamic ability on animations,
          they're either stateful or not.

  RESOLVED: Not have a dynamic ability on animations, they're either
            stateful or not.

  Rossen: Do we need to expose this is the next question.
  majidvp: We want to give author a way to differentiate between the
           two. I'm in favor of exposing and letting authors say what
           their animation is. Mechanism I'm impartial. We can have
           the bool on the class, we can have different parent classes.
  Rossen: Because you're basing things on the fact that people can
          take advantage of this performance, can you give us an
          example of that?
  majidvp: If you want to impl parallax. It doesn't have state, just
           translates input to state. If we say it's stateless the
           browser can produce more animations and avoid running JS.
  majidvp: It's more obvious when animation is time based. In one
           animation worklet you run the thread once and get multiple
           frames. For stateful you can't do that because producing
           one frame might not be there in the next sequence. You're
           losing some performance benefit.
  majidvp: Our impl doesn't run in parallel.
  Rossen: By construction you're impl will know if it's stateless or
          stable.
  majidvp: How would you know.
  smfr: Parsing state in constructor.
  Rossen: Oh. So we resolved by construction they are stateful or
          stateless So you know if this is one or the other. You don't
          need to ask anymore. Attribute you'd need in case you change
          your mind, but I don't see anything dynamic.
  flackr: How do you construct it?
  Rossen: You tell me.
  flackr: This was a static class to say.
  majidvp: Other option would be construction for worklet takes in a
           state object that's passed into an animation instance. If
           it's undefined or null it's stateless.
  Rossen: Yeah.
  majidvp: We have an object called options. We use it to pass things
           the animation needs to know. It's similar. I wouldn't mind
           that.
  Rossen: That way everyone is kind of happy. birtles is happier.
  birtles: I was looking for other options, but yeah. I put on the
           issues two other things about the constructor. May be other
           possibilities with switching.
  majidvp: You don't have to provide when you do the animation that
           you have 2 arguments it's stateful.

  [brief break due to IRC issue]

  majidvp: birtles proposal in the issue is nice and ergonomic. If it
           has 2 arguments it means second is state.
  majidvp: Number of arguments.
  iank: You can't look at the shape of arguments.
  Rossen: Your versioning becomes crazy.
  birtles: It's common in JS libraries.
  iank: Are you switching inside of native code here?
  iank: When you call the register animation, you're looking for
        arguments, that doesn't work. That's not failable.
  birtles: Call .length
  majidvp: If you call .length it gives you number of required params
  majidvp: If you have optional parameters, in webIDL at least.

  birtles: There's another option further down.
  majidvp: I don't think second is possible. Can you differentiate
           between class and function?
  TabAtkins: No, class returns a function.
  smfr: I think check is constructible?
  majidvp: Any is constructible.
  gsnedders: Not in webIDL.
  majidvp: This is user provided.
  gsnedders: Then it does have construct.
  birtles: Point I was trying to make is that we don't necessarily
           need an attribute.
  Rossen: Checking number of arguments is defined. You can check the
          length.
  shane: I think there is a more disciplined argument about having it
         as a parameter because it's clear to people making the code.
  birtles: I think it's quite intuitive to check the callback function.
  Rossen: One of the versioning schemas we have in our API is based on
          number of parameters.
  shane: It's a technique. But we're designing an API. It's bad design
         to change fundamentally different behaviors based on magic.
  birtles: I hear you, but I see it so much I think it's idiomatic.
  fremy: Relying on number or arguments is a problem when you need
         state and it's in the constructor...people use [missed] and
         if you don't put something in the argument it throws an
         error. Also if we ever need a 3rd argument in the future
         you're screwed. Maybe we have a default value so if you have
         that you don't need to do anything special.
  iank: It works on top of the class, but if you extend something it
        doesn't work.
  majidvp: Number of arguments works in webIDL because it has syntax
           to say which params are optional. normal JS doesn't have
           that concept. When you call a function at run time you know
           number arguments passed through. You use that to choose one
           behavior or another. As an engine I think you'll have a
           hard time.
  shane: The experiment from iank shows you can't do it at top level.

  birtles: I'm not sure we want to decide now, it's discussion to have.
  Rossen: One of the things...the whole discussion was do we need the
          attribute or not.
  shane: Isn't going back to the issue likely to push it to the WICG?
  birtles: We can take it offline.
  shane: F2F is when we do things in person.
  birtles: Wednesday afternoon, then, during the breakout?
  shane: You want to think about it more.

  Rossen: Let's summarize. We don't want the attribute. To avoid that
          we can pass the info through the parameter list and base the
          statefulness on that. That was mildly argued against since
          it's not clean design from internal API, though it's common
          for JS developers.
  Rossen: We can resolve on nothing and keep the param for now, or we
          fast forward and resolve on the parameter and then bring
          other ways to do this if it's hard to impl or bad behavior.
  Rossen: What do we want to do. Stay with static or number of
          parameters on construction?

  smfr: Two super classes was an option.
  majidvp: We haven't discussed that
  flackr: If statefulness defaulted to stateless when not spec you get
          behavior that you want.
  majidvp: Which is a good default to have.
  shane: There's no signal it's a sure thing. I think you're expecting
         a state and it doesn't appear. I think being explicit is more
         clear.
  flackr: You could throw if there is no state.
  shane: That would be okay....it covers knowledge.

  Rossen: Going back to three choices, I liked the 3rd, have the
          stateful and stateless classes. It makes it one or the other
          and satisfies the pushback against the attribute.
  Rossen: Going forward if we discuss again and have something better
          we can re-discuss. But let's not lose the opportunity to
          resolve.
  majidvp: The super class if you want to allow dynamic it doesn't
           allow for that.
  shane: Not just a third class?
  majidvp: Okay....you're using a heavy hammer for something that
           could be an attribute. Attributes are very common.
  shane: If there's a state object and you're in stateless version
         it's there. If you do have the hybrid later you can have
         explicit functions for switching.
  Rossen: You can always have a conversion function based on object
          data.
  majidvp: Okay...that's not bad. I buy having the state object as a
           super class and then have setters.
  Rossen: Other opinions?
  Rossen: Objections to introducing 2 classes as a mean to listing
          stateful and stateless types?

  RESOLVED: Introduce 2 classes as a mean to listing stateful and
            stateless types.

Implementation status update and plans for origin trial
-------------------------------------------------------

  majidvp: Last F2F we committed to new direction for the API bringing
           it closer to web animation. We've gone ahead to have our
           impl match the new direction.
  majidvp: I wanted to give you an update.
  majidvp: We've impl an animation object on the main thread that can
           play and cancel animation on the worklet. Full API isn't
           impl since Blink animation has complexity.
  majidvp: We've also impl scroll timeline which is the avenue for
           animation worklet to read and be found through scroll.
           That's been working well. We've been providing feedback to
           scroll timing spec.
  majidvp: Also working on compositor to allow control from a separate
           thread.
  majidvp: All is working. Need to work more on performance and look
           for areas not fully optimized.
  majidvp: Impl is buggy in some cases, but working on it.
  majidvp: Future plan is polish API and stabilize and run an origin
           trial. It won't be the full spec, it's a similar use case
           that doesn't have access to multi timeline or access to
           group elements. I don't think we want that complexity for
           an origin trial.
  majidvp: Surma has been working with the API.

  surma: Here's the demo (requires Canary). I've been working with the
         new API. It was limited but got a lot of attention.
  <surma> Twitter demo:
https://cdn.rawgit.com/GoogleChromeLabs/houdini-samples/aw-update/animation-worklet/twitter-header/index.html
  surma: First insight is majority of effects can be done with web
         animations and scrollType. That being said, it won't hold
         once you want to make things stick to a finger or animate in
         2 directions.
  surma: I can't experiment right now, but the UA design is nice. If
         we think about timing functions you'll likely draw the line
         and make a manual timeline.
  Rossen: Gist of the demo is?
  surma: The header goes into the top bar.
  surma: Awkward thing is web animations are all about measuring
         things and depend on screen size and scrollbar size. All the
         ratios change and you have to be able to change your
         timeline. It's not necessarily nice.
  surma: If you could get timeline of scrollbar you'd have to measure
         that.

  surma: Another thing, with scrolling timelines you define the time
         span where it starts at 0ms and goes to 5000ms. I was going
         0-1 but we round up.
  majidvp: We round up to micro seconds. Internal impl have micro
           seconds. If you have a large scroll it can be smaller then
           micro second.
  surma: I'm not sure if we need to choose the time or if we don't
         think people will run into the 0-1 issue.
  surma: Also because we can fall back to main thread we should expose
         where this is running.
  surma: It may be in the spec.
  flackr: It's not. Not since we went to pure web animations.
  surma: Other APIs allow to propagate to worklets, would be nice here.
  flackr: I think we have update options.
  majidvp: We haven't done it, there's notes saying we could do that
           way.
  majidvp: Similar to layout worklet and using other inputs. We should
           be able to come up with a solution for when you update.
  majidvp: If there isn't any follow-up we can move on.

Request to move the spec from WICG to WG as FPWD
------------------------------------------------

  Rossen: What was the policy around moving out of WICG? Was it 2
          major impl with intention to impl? What were the
          requirements?
  ChrisL: Was that defined by them or us?
  fantasai: We didn't have rules.
  fantasai: If WICG wants to give us something and we'll take it then
            we're fine. If they object to us taking something then...
  Rossen: I don't expect them to object to us working on something.
  Rossen: Assuming there's no process hurdles, any objections to
          moving the spec under Houdini and going for FPWD?

  Rossen: Has anyone read the spec?
  [a few hands raise]
  <fantasai> 4-5 people reviewing a spec not all from the same company
             is pretty good tho!
  majidvp: This is part of why I want to move it to Houdini. To get
           attention. Also there is common elements to the worklet
           specs so we can take them together. Animation worklet
           didn't move to CSS namespace because it was in a separate
           repo.
  Rossen: I guess I was provoking a discussion to people objecting to
          adopting this spec over the last F2F. The objections before
          were why isn't this on top of web animations, do we need
          this? Before we adopt as FPWD it would be good to answer
          these questions.
  Rossen: I don't want to stop the work, quite the opposite, but I
          recall the other side of the argument. Have we answered
          those questions? Can it be and should it be done this way?
  Rossen: I remember dino pushing back on this in Tokyo.
  majidvp: One of the things we did in Tokyo...most of the pushback
           was before Tokyo. In response we did this rework to be
           compat with animation. From the main thread these are
           animations, but additionally customizable. I think that was
           one of the major feedbacks and we tried to address it. In
           Tokyo we got good feedback and we haven't made major
           changes since then.
  krit: For me it's not clear...when I read to spec it seems like you
        want to spec the model you're doing in blink cross platform.
        When you talk about web animations they're still the main
        thread and the worklet is off thread. It's not clear from the
        intro how they interact.
  krit: Before this goes to FPWD it needs to have normative and
        non-normative text indicated. You should avoid things like
        branding with the twitter example. Seems to be a short spec,
        not sure if it needs to be bigger, though.

  Rossen: We have another option. We move the spec to CSS/Houdini repo
          and continue as an ED. We can go for FPWD at the next F2F or
          over email. FPWD has a special weight to it. If you want to
          move work to Houdini that's easier.
  majidvp: I knew FPWD is a good time to get objections. If there are
           major objections I'd like to hear them.
  krit: FPWD also has intention that the group will work on the spec
        and test.
  majidvp: On impl side Chromium is committed to work on this. As I
           said we're trying to do an origin trial. That would be
           good. I don't think any other impl has said they plan to
           impl.
  majidvp: But I don't think that's a FPWD requirement.
  astearns: We want to make sure no one objects to eventually
            implementing and have an idea there is a schedule they
            will evaluate. Moving to Houdini repo will get more eyes.
  Rossen: Agree.

  astearns: You are not a WG member.
  majidvp: Correct. flackr is a co editor and he's a member.
  Rossen: The spec has 3 editors and flackr is the only member.
          Stephen isn't a member of any group.
  astearns: They're from a member organization, though.
  Rossen: One thing at a time. First thing is to move the spec from
          WICG to CSS Houdini drafts.
  Rossen: Objections?

  RESOLVED: Move the spec from WICG to CSS Houdini drafts

  Rossen: Do we have enough people that have reviewed to publish as
          FPWD or wait?
  astearns: I think we need to address the little details like
            normative and non-normative text
  birtles: One more details it has a dependency on scroll driven
           timelines. Should we move that over?
  birtles: It's a more fundamental piece and this has a enormous
           dependency.
  fantasai: Seems reasonable.
  Rossen: Who edits that?
  majidvp: I think birtles is one of the editors.
  <birtles> https://wicg.github.io/scroll-animations/
  majidvp: It takes the timeline and it could be a scroll timeline.
  birtles: It's normative
  majidvp: Yeah. We use it, but similar to other timelines.
  birtles: Maybe not necessary then.
  Rossen: I don't see a reason why we wouldn't take it.
  Rossen: This is you and some Mozilla folks birtles?
  birtles: They're not really working on it, I'm not really either.
  Rossen: Do we need to move it?
  birtles: I'm suggesting we leave it.

  Rossen: Back to the previous question, it sounds like there are a
          number of normative changes to do before we can publish
          FPWD. I would encourage people to read the spec and provide
          feedback. Then we can get FPWD over telecon or in Sydney.
  astearns: I think non-Google editor would be good.
  majidvp: If birtles can edit that would be awesome.
  majidvp: The dependency on scroll timeline if we ship animation
           worklet we want to do scroll timeline at the same time so
           progress on them in parallel.
  Rossen: First action for you is the people currently editing
          animation worklets as your AC rep to nominate you as WG
          members. Then figure out how to get birtles to join you as
          an editor.
  Rossen: Objections to adding birtles as an editor?
  birtles: I'm not sure I can commit to the time.
  birtles: Let me look into it.
  Rossen: We can discuss editors when we do FPWD and go from there.

  Rossen: Second action was for you to move the spec.
  majidvp: I've done the move to CSS before so I think I know how to
           do it.
  Rossen: Last action for majidvp, address the feedback.
  Rossen: Everyone else read the spec.
  plinss: Short name?
  plinss: css animation worklet?
  majidvp: CSS Animation API?
  Rossen: Sounds good.
  birtles: Is that confusing with CSS Animations?
  nainar: It sounds like Animations
  Rossen: CSS Houdini Animation API ^-^
  nainar: CSS Animation Worklet
  ??: Custom Animation?
  Rossen: CSS Animation Worklet. Any objections?

  RESOLVED: CSS Animation Worklet

  astearns: We'll likely revisit at FPWD.

  <birtles> for the record, concern with using CSS Animation API is
            that if you want to inspect a CSS Animation you don't use
            the CSS Animation API--you use the Web Animations API

Paint API
=========

Rename paint(name, args) to paint-name(args)
--------------------------------------------
  github: https://github.com/w3c/css-houdini-drafts/issues/751

  leaverou: I was suggesting that since the item with the first param
            defines what is being painted it should be part of the
            function name. So it should be paint-blah(arg). It reads
            more clearly and separates it from the arguments. Current
            situation is very hard to read. It makes the thing being
            panted the name level of it's parameters.
  leaverou: I think besides the ability issue, it reads much more
            naturally.
  TabAtkins: We decided against the approach back when we were doing
             var. The property is --foo and the var is --foo. This is
             similar. If you don't have a requirement to register your
             paint functions with the name you have the same problem.
             If we do require it we can but that feels strange and
             restricts what we can do later with a sub-version of
             paint.
  leaverou: Variable was defined and references in CSS. Here's it's
            split between CSS and JS. JS identifier with a CSS
            function. In var it was both in the same place. The CSS is
            consistent with this.
  TabAtkins: But one person could have written variables file and
             another person is using it. The difference of authors
             applies.

  dbaron: Another issue is readability and understanding a new feature
          you see in code. With the combined name you find paint-foo
          and it sounds like a CSS feature but there's no search
          results. There's nothing that says the name is part CSS.
  leaverou: Because it reads more naturally. You're saying make it
            unnatural so people are confused.
  dbaron: Make it two parts so people understand. If you put them
          together and they look like one thing it's hard for people
          to recognize it's two pieces.
  TabAtkins: When we have custom functions in CSS you can have
             whatever names you want with a -- at the front.
  fremy: I agree with the point it's tricky to parse. One argument I
         like is auto-completion is getting supremacy. But I also
         don't like putting function in.
  dbaron: If you want to fix the function you can do a nested function.
  leaverou: If your paint takes functions that also have parameters
            you end up with lists.

  <astearns> is paint(company-logo()) and paint(chat-bubble(blue)) a
             terrible idea?
  <dbaron> I wonder if the first could still just be
           paint(company-logo)
  astearns: I suggested that earlier in IRC which addresses having the
            function and it's elements at the same level.
  leaverou: What if we came up with a syntax that doesn't have the
            nested param. What if it's a keyword.
  astearns: I'm convinced by dbaron where if you see a function in the
            value of a CSS you should be able to search for it to
            figure out what it is. Having something I can Google is
            easier then knowing some portion would need to be
            extracted.
  <ChrisL> good luck searching for 'paint' though
  <fremy> @ChrisL: works for me:
https://www.google.de/search?q=css+paint&oq=css+paint&aqs=chrome..69i57j0l5.1307j0j7&sourceid=chrome&ie=UTF-8

  leaverou: Can you imagine this argument in any other language?
  TabAtkins: JS swallows the compat issue of user stuff and browser
             stuff being in the same place. We stay away from that.
  fantasai: None of the parameters to a function are attached to a
            name.
  leaverou: In JS you can create your own functions.
  dbaron: But not that you get an additional name.
  leaverou: In CSS you don't have . notation so you can't do what JS
            does here.
  TabAtkins: Exactly
  leaverou: Only separator we have is the hyphen.
  TabAtkins: But it's not for separate origins thing.
  Rossen: Alright. Any more arguments?

  leaverou: What if it remains as an argument but it's separated in
            another way like a /
  TabAtkins: We don't use / unless required by parsing.
  astearns: And anything other then nested parentheses would be
            confusing.
  <TabAtkins> It would mean you can't create a function that returns
              an ident, and use that to select the paint function you
              want. ^_^
  flackr: I also find it confusing because the thing you're defining
          is a class.
  leaverou: That's impl detail to a CSS author.
  fremy: I foresee it being used for [missed]. As a CSS author you
         only care what you give to the conic gradient.
  leaverou: As a polyfill I find it harder to say you do a conic
            gradient and then the other arguments depend on what your
            arguments are.
  leaverou: The one parens give you more places for people to screw up.

  Rossen: There is a couple ways to go forward. Discussion is going in
          two parallels. We can vote to decide on one or the other or
          we can stop and discuss in github.
  leaverou: Might be better for people to think so if we continue in
            GH issue.
  shane: I think same argument applies, this is the space where we
         come to agree.
  TabAtkins: It was just brought today, though.
  shane: Fair. But if we resolve it's not the end of the world we can
         revisit.
  Rossen: True. We can look for a resolution.
  krit: We have the paint function and a resolution for it.
  Rossen: We want a resolution to not change so we can mark it in the
          issue.
  Rossen: Before I call for a straw poll, any other closing arguments?
  Rossen: I've heard so far strong reasons against changing and
          readability and usability PoV a preference toward hyphenated.
  leaverou: And for documentation. It's easier to explain that this is
            a new function you can use then if you use paint function
            the first value is fixed.
  Rossen: Let's try to resolve by objection first.
  Rossen: Would there be objections to not changing the Paint function
        and custom paint function registration?
  shane: Does anybody object to closing this issue no change?

  RESOLVED: Paint function and custom paint function registration does
            not change.

  Rossen: I would suggest continuing discussion on this.

Publication
===========

  nainar: Should any specs move to the next stage? If we can get
          timelines...otherwise nothing gets done.

  Rossen: CSS Box API
  Rossen: This is in WICG?

  <Rossen> https://drafts.css-houdini.org/
  Rossen: Spec list ^

  TabAtkins: 4 today plus properties and values are the only ones
             being worked.
  Rossen: And worklets
  Rossen: Layout API is currently a WD.
  Rossen: No, it's not.
  iank: I think I forgot to change it to ED.

  Rossen: Ready for FPWD on Layout API?
  iank: Yeah.
  fantasai: We have a resolution.
  gsnedders: We've resolved at least twice.
  fantasai: Action was on ChrisL to publish back in August.
  fantasai: iank should have followed up, but I put it on Chris's plate
            this morning.

  dbaron: Is there an issue tracking system for publication?
  ChrisL: Yes.
  Rossen: So action is on ChrisL to publish this.
  <fantasai> https://lists.w3.org/Archives/Public/public-houdini/2017Aug/0003.html

  Rossen: Painting API
  surma: I think it when to CR
  Rossen: In 2016.
  fantasai: Was it ever published in CR?
  Rossen: No.
  ChrisL: You sent me an email I told you why it hadn't been
          published, I never heard back. It doesn't have most of the
          things required for CR.
  Rossen: I will find your list, ChrisL and ask iank and/or shane to
          followup. DoC and Wide Review are missing.
  Rossen: And then this can go CR.
  Rossen: In the meantime no reason not to publish a new WD.
  shane: Publish a WD, send it to the appropriate groups, and then
         request CR.

  RESOLVED: New WD for Painting API

  Rossen: Properties & Values
  TabAtkins: Published late last year. I can check if there have been
             edits.
  Rossen: So no reason for a new WD? Last publish was November.

  Rossen: Typed OM.
  nainar: Probably need a WD
  TabAtkins: It needs a new WD. I may try and publish now and then do
             one after the edits from today.
  dbaron: Some previous version links are wrong.

  RESOLVED: Publish new WD of Typed OM

  Rossen: Worklets probably needs a refresher.
  Rossen: Last publish was June 7 2016. Reason to not have a new WD?
  Rossen: iank?
  iank: nope.

  RESOLVED: Publish a new WD of Worklets L1

  ChrisL: I'm filling in the thing on the transitions and I'm noticing
          Houdini specs don't have abstracts.

  Rossen: Font Metrics. Did we move this to WICG?
  several: I don't think so.
  iank: The November was dbaron fixing meta data.
  Rossen: Is there a reason to keep this in Houdini or move to WICG?
  astearns: I think we resolved to WICG.
  Rossen: I think same is true for Box 3 API
  Rossen: That's it. fantasai did you uncover anything else?

  fantasai: I'd like to see these things published this week. I bring
            this up and then wait 6 months and then it's not published.
  dbaron: And I put the W3C IDs to the specs to make it easier.

  Rossen: Any other housekeeping? If not we're done with the agenda?

  Rossen: One last thing: Some of the folks helping us are stepping
          out of WGs including Houdini. That includes shane as well as
          ericwilligers and nainar who are moving to other internal
          projects. I want to thank them for all the work you've each
          done.
  Rossen: Thank you so much.

  Rossen: We are adjourned.
Received on Thursday, 26 April 2018 00:29:33 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 26 April 2018 00:29:34 UTC