- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 25 Apr 2018 20:28:31 -0400
- 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