- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 07 Jun 2019 17:57:37 +0000
- To: public-houdini-archive@w3.org
The Houdini Task Force just discussed `Custom functions`, and agreed to the following:
* `RESOLVED: Draft this proposal up as css-functions-api`
* `RESOLVED: TabAtkins and AmeliaBR as editors`
<details><summary>The full IRC log of that discussion</summary>
<TabAtkins> Topic: Custom functions<br>
<fantasai> ScribeNick: fantasai<br>
<TabAtkins> https://github.com/w3c/css-houdini-drafts/issues/857<br>
<fantasai> AmeliaBR: This is a proposal for a new module to have a way to have custom functions that you could use in CSS values<br>
<fantasai> AmeliaBR: Math functions, color functions, things that you put in a CSS value and it evaluates to an existing value type<br>
<fantasai> AmeliaBR: I sketched up a rough API in the proposal<br>
<fantasai> AmeliaBR: There's been good discussion over the past few months<br>
<fantasai> AmeliaBR: We separated things out into "stuff that can be easily isolated" vs. "stuff that is complicated"<br>
<fantasai> AmeliaBR: Looking at existing functions we have in CSS<br>
<fantasai> AmeliaBR: We have ones like the new math functions<br>
<fantasai> AmeliaBR: where they take an input value and output value<br>
<fantasai> AmeliaBR: end result is always the same for the parameter you gave<br>
<fantasai> AmeliaBR: sin(90deg) will always be sin(90deg), doesn't depend on the element<br>
<fantasai> AmeliaBR: On the other handl calc(percent + pixels) can't be evaluated until layout<br>
<fantasai> AmeliaBR: So that's simple idempotent functions that can do isolated<br>
<fantasai> AmeliaBR: vs ones that dpeend on DOM tree, inheritance, etc.<br>
<fantasai> AmeliaBR: proposal at the time is to create Level 1 custom functions that only address the isolated idempotent case<br>
<fantasai> AmeliaBR: always gives the same result for same parameters<br>
<fantasai> AmeliaBR: Except that we also allow putting in custom properties<br>
<fantasai> TabAtkins: Also allow *<br>
<heycam> q+<br>
<fantasai> AmeliaBR: There will be arguments to the function, when you use the function you will know what they are<br>
<fantasai> AmeliaBR: One other issue that came up in the discussion<br>
<fantasai> AmeliaBR: what is the structure for declaring your custom function<br>
<fantasai> AmeliaBR: I based it on Paint API<br>
<fantasai> AmeliaBR: valid suggestion that maybe that's overkill and doesn't need a custom class<br>
<fantasai> AmeliaBR: and maybe just need a registration object<br>
<fantasai> AmeliaBR: in this case one of the items of those configuration object would be an actual JS function<br>
<fantasai> AmeliaBR: that's a point of debate<br>
<fantasai> AmeliaBR: Qeustion is do we go with class-based API or simple config option<br>
<fantasai> myles: Runs in a worklet?<br>
<fantasai> AmeliaBR: Yes, actual evaluation of function would be in a worklet<br>
<fantasai> AmeliaBR: either way we need some isolated module so the function is defined in the global scope<br>
<fantasai> AmeliaBR: So doing custom property where you're registering all the data in the main thread doesn't work because the function you're including has to be in a separate module<br>
<fantasai> myles: Style resolution can be multithreaded<br>
<fantasai> myles: Is that compatible with this proposal?<br>
<fantasai> heycam: Our style resolution is multithreaded<br>
<fantasai> myles: potentially one day ours might be too<br>
<fantasai> AmeliaBR: So long as you do dependency calculation for cross-references<br>
<fantasai> AmeliaBR: have to think of those dependencies<br>
<fantasai> AmeliaBR: but function itself is very isolatable<br>
<fantasai> TabAtkins: Ths is basically JS-computed var functions<br>
<fantasai> TabAtkins: ...<br>
<fantasai> emilio: Style resolution includes value computation<br>
<fantasai> iank_: Architecturally this would be impossible<br>
<fantasai> myles: Paint has the same requirements<br>
<fantasai> iank_: Paint has the ability to run on multiple hreads<br>
<TabAtkins> q?<br>
<emilio> q+<br>
<bkardell_> s/hreads/threads<br>
<astearns> ack heycam<br>
<fantasai> heycam: I was going to ask about the worklet stuff as well<br>
<fantasai> heycam: Is it that we have to wait for worklet to synchronously finish its computation<br>
<fantasai> heycam: e.g. on getComputedStyle?<br>
<fantasai> heycam: Is that also what happens with layout?<br>
<fantasai> iank_: If you call layout, we'll synchronously wait for it to finish<br>
<fantasai> TabAtkins: have to run layout on getComputedStyle for width<br>
<astearns> ack fantasai<br>
<TabAtkins> fantasai: If the value can't change on properties of the element, etc, what are the intersting things we can compute here?<br>
<emilio> fantasai: If the value can't change the properties of the elements and what not what's this useful for?<br>
<emilio> ... it cannot even depend on lengths<br>
<emilio> AmeliaBR: custom color mod functions, custom math functions<br>
<emilio> TabAtkins: because we're waiting for computed value time, your ems are fine for example<br>
<emilio> ... we can resolve lengths beforehand<br>
<emilio> fantasai: oh you can resolve lengths<br>
<emilio> AmeliaBR: yeah, not percents since they depend on layout<br>
<fantasai> s/resolve lengths/resolve lengths; I had the impression from Amelia that you couldn't because length resolution varies per element and depends on e.g. font resolution<br>
<emilio> TabAtkins: the restrictions mean that it's not guaranteed for your function to be called for every element that matches it if they have the same input<br>
<emilio> emilio: then how does that work with multi-threading?<br>
<emilio> TabAtkins: you're not required to not call the function multiple times<br>
<heycam> q+<br>
<emilio> AmeliaBR: you always get the same result<br>
<emilio> emilio: but you can't guarantee that<br>
<fantasai> ...<br>
<fantasai> TabAtkins: Because you can invalidate apainter whenever, if you use random value it can flicker<br>
<fantasai> TabAtkins: same result here<br>
<fantasai> AmeliaBR: We can't force the Web author to write idempotent functions<br>
<fantasai> AmeliaBR: But can say browser is allowed to assume the function is idempotent<br>
<fantasai> emilio: If they write a non-idempotent, am I allowed to eat their laundry?<br>
<fantasai> dbaron: invalidation thing is useful for debugging<br>
<fantasai> [emilio's comment got lost in translation]<br>
<fantasai> myles_: ...<br>
<fantasai> AmeliaBR: if you look through issue discussion, brainstormed some ways that you could define just the right amound of randomness<br>
<fantasai> AmeliaBR: do you want random per element -- same element gget same result<br>
<TabAtkins> s/.../so how do you implement random() with this?/<br>
<fantasai> AmeliaBR: or random per element + property -- different result per property?<br>
<TabAtkins> TabAtkins: you can't implement random() at this level<br>
<fantasai> AmeliaBR: That's part of the thing that's too complicated to deal with right now<br>
<fantasai> TabAtkins: Have plans for that, but not worry about that right now<br>
<fantasai> TabAtkins: want to handle things like more math functions without going through WG<br>
<fantasai> myles_: So hashing?<br>
<majidvp> q+<br>
<fantasai> TabAtkins: yeah<br>
<emilio> ack emilio<br>
<fantasai> AmeliaBR: This is all about saying that browsers have a set of things they're looking at for when result will be invalidated, then it will be rerun<br>
<fantasai> AmeliaBR: They can also rerun whenever convenient<br>
<fantasai> AmeliaBR: that's the contract to authors<br>
<Rossen_> ack heycam<br>
<fantasai> heycam: This might already be partially answered by what happens in custom layout<br>
<fantasai> heycam: but what happens when worker throws exception or times out?<br>
<fantasai> TabAtkins: invalid at computed value time<br>
<fantasai> heycam: also the case that with custom layout, you just have to wait until browser decides it wants to recalculate that it will try again?<br>
<fantasai> TabAtkins: whenever your inputs are changed, we invalidate<br>
<fantasai> TabAtkins: or whenever the browser feels like it<br>
<fantasai> myles_: wouldn't want it to be observable<br>
<fantasai> TabAtkins: If you had something that mapped out random < .5 throws exception<br>
<fantasai> TabAtkins: "please run me again I'll do better!"<br>
<fantasai> TabAtkins: browser will run whenever not because you failed<br>
<fantasai> myles_: ...<br>
<fantasai> TabAtkins: randomness is ill-defined<br>
<Rossen_> q?<br>
<emilio> q+<br>
<myles_> s/.../presumably this would have the same thing as custom paint where it would throw away the world every so often?<br>
<fantasai> majidvp: When I sw this proposal immediately what came to mind is our discusison yesterday about easing functions for animations<br>
<fantasai> majidvp: The current use case is focused o nstyle resolution<br>
<fantasai> majidvp: but idea of stateless function with results cachced<br>
<fantasai> majidvp: is similar to what we want fo reasing<br>
<fantasai> majidvp: I'm interested to see if we can make the design such that it can be used for ?<br>
<fantasai> majidvp: example, one could have ?<br>
<fantasai> majidvp: you don't bind all the arguments at styele resolution<br>
<bkardell_> s/?/partial currying<br>
<myles_> q+<br>
<fantasai> majidvp: create function with some paratmeters bound at style resolution<br>
<fantasai> majidvp: and one varible, % progress, that gets fed in<br>
<fantasai> AmeliaBR: way to think about it is, easing fucntion in CSS is a function that returns as its value an f(x) type function<br>
<fantasai> AmeliaBR: custom CSS function could return a function that was used as an easing function<br>
<fantasai> AmeliaBR: to do that, we'd need a TypedOM representation of an easing function<br>
<fantasai> AmeliaBR: Would be useful to create a custom easing function<br>
<fantasai> AmeliaBR: right now they're defined in a string<br>
<fantasai> AmeliaBR: but custom one, already talking about<br>
<fantasai> AmeliaBR: knock out lost of use cases for custom animation worklet<br>
<fantasai> AmeliaBR: wrap it up in a TypedOM object<br>
<fantasai> AmeliaBR: then your function in this proposal would return such an object<br>
<fantasai> AmeliaBR: that represents the easing function<br>
<fantasai> myles_: Why can't you animate the input?<br>
<fantasai> AmeliaBR: I think there's some circulatrity there<br>
<fantasai> TabAtkins: This proposal is not meant to produce new value ypes<br>
<fantasai> TabAtkins: takes input to provide existing value type<br>
<fantasai> TabAtkins: if we need some new type of value, that would be a separate proposal<br>
<fantasai> TabAtkins: once accepted could be something these functions can output<br>
<fantasai> AmeliaBR: Myles was saying ...<br>
<fantasai> AmeliaBR: converting your x progress to the change you want to have<br>
<fantasai> AmeliaBR: indirect way to get what you want<br>
<fantasai> majidvp: basically bypassing web animations machinery<br>
<fantasai> ...<br>
<Rossen_> ack majidvp<br>
<fantasai> TabAtkins: You can use a transition delay to set exactly where in the animation you want to be at that moment<br>
<emilio> ack emilio<br>
<fantasai> ?: Thing deciding your animation position is being decided by another animation<br>
<fantasai> myles_: We have that in animating custom properties<br>
<fantasai> myles_: you animate custom property x from 0 to 1<br>
<fantasai> myles_: you say left: custom-function(..x)<br>
<fantasai> ?: will come up with the ?? proposal<br>
<fantasai> flackr: ...<br>
<AmeliaBR> `.el { width: custom-func(0px, 100px, var(--x)); --x: 0; transition: x 0.3s linear;} .el:hover { --x: 1}`<br>
<fantasai> s/?:/flackr:/<br>
<fantasai> s/?:/flackr:/<br>
<fantasai> myles_: Do we need extra facilities?<br>
<fantasai> myles_: are we going to try to make custom functions return more functions?<br>
<fantasai> majidvp: no<br>
<fantasai> majidvp: I don't think we should do that, was just thinking<br>
<fantasai> majidvp: happy to limit right now<br>
<fantasai> AmeliaBR: Right now custom functions return TypedOM objects<br>
<fantasai> AmeliaBR: if we later have TypedOM objects for easing functions, it'll come along for the ride<br>
<Rossen_> ack myles_<br>
<fantasai> myles_: In the GH issue it shows that the return type is a single type<br>
<fantasai> myles_: but a CSS variable can expand to a sequence of things<br>
<fantasai> TabAtkins: No we don't need a return type if we build on variable machinery<br>
<flackr> s/.../This will come up with our resolution on #869 where we can animate property --x from animation A and read that property in animation B to produce property --y.<br>
<fantasai> TabAtkins: you can output arbitrary, if you want to do that with TypedOM, you represent it as CSSUnparsedValue<br>
<fantasai> AmeliaBR: Not as usefut to return an unparsedValue<br>
<fantasai> AmeliaBR: but I expect TypedOM to return lists ad other complex types<br>
<fantasai> emilio: does this mean these nee to be handled like variable references<br>
<fantasai> TabAtkins: yeah<br>
<fantasai> TabAtkins: you look sad :(<br>
<fantasai> emilio: No, it's OK<br>
<fantasai> s/OK/fine<br>
<Rossen_> q?<br>
<fantasai> emilio: but that means the input can be anything as well<br>
<fantasai> emilio: so same implications that ppl complain about<br>
<fantasai> AmeliaBR: same resolutions as references in paint<br>
<fantasai> TabAtkins: I still should change that to be not like variables, but at least for now will be more like variables. Can add more strongly typed later<br>
<fantasai> TabAtkins: Questions like "what happens if throws an error" get answered that way<br>
<AmeliaBR> s/change that/change env()/<br>
<fantasai> ...<br>
<fantasai> emilio: How do you resolve relative units?<br>
<fantasai> emilio: If input is unparsedvalue<br>
<fantasai> heycam: inputs are typed<br>
<fantasai> emilio: so input syntax is in the definition of the function<br>
<fantasai> TabAtkins: Yes. Unless you say *. But if you say <length> ems will resolve<br>
<TabAtkins> q?<br>
<fantasai> TabAtkins: I think I'm ready to write a spec for this if no one objections<br>
<fantasai> AmeliaBR: I will happily let you the work, but also happy to continue involved<br>
<fantasai> bkardell_: co-editor involved?<br>
<fantasai> AmeliaBR: sure<br>
<fantasai> [naming discussion]<br>
<fantasai> myles_: This has a bunch of JS stuff too<br>
<fantasai> Rossen_: So proposed resolution is Tab and Amelia to co-edit CSS Custom Functions<br>
<fantasai> [more naming discussions]<br>
<bkardell_> ?<br>
<fantasai> bkardell_: I like keeping custom in there because it's not immediately clear to everyone that -- is our universal custom thing<br>
<fantasai> bkardell_: so ties it in that way with custom properties<br>
<fantasai> css-functions<br>
<TabAtkins> css-functions-api<br>
<fantasai> function-api<br>
<dbaron> CSS Value Functions (as fullname)<br>
<bkardell_> sepia-mode<br>
<fremy> +1 to <css-funcs> CSS Value Functions<br>
<bkardell_> +1 css functions api for the short name<br>
<Rossen_> CSS Custom Functions<br>
<fantasai> bkardell_, did you mean css-functions-api<br>
<flackr> +1 css-functions-api<br>
<fantasai> ?<br>
<bkardell_> yes<br>
<bkardell_> I am saving all my dashes fantasai for custom things<br>
<AmeliaBR> short & sweet, css-functions<br>
<fantasai> RESOLVED: Draft this proposal up as css-functions-api<br>
<fantasai> RESOLVED: TabAtkins and AmeliaBR as editors<br>
<bkardell_> also resolved to include Custom in the title?<br>
<fantasai> Rossen_: That's it for Houdini<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/857#issuecomment-499980921 using your GitHub account
Received on Friday, 7 June 2019 17:57:40 UTC