07:20:16 RRSAgent has joined #houdini 07:20:17 logging to https://www.w3.org/2018/04/09-houdini-irc 07:20:19 RRSAgent, make logs public 07:20:19 Zakim has joined #houdini 07:20:21 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 07:20:21 Date: 09 April 2018 07:21:42 dael has joined #houdini 07:22:13 emilio has joined #houdini 07:22:24 Rossen Atanassov, Microsoft 07:22:38 cbiesinger has joined #houdini 07:22:40 Dirk Schulze, Adobe 07:22:43 fantasai has joined #houdini 07:22:54 Shane Stephens, Google 07:22:54 Tab Atkins, Google 07:22:56 Ian Kilpatrick, Google 07:23:07 Alan Stearns, Adobe 07:23:07 Naina Raisinghani, Google 07:23:08 smfr has joined #houdini 07:23:09 present+ Surma, Google 07:23:16 Christian Biesinger, Google 07:23:17 present+ Simon Fraser, Apple 07:23:21 fantasai / Invited Expert 07:23:26 present+ 07:23:31 Rune Lillesveen, Google 07:23:35 David Baron, Mozilla 07:23:37 Peter Linss, Invited Expert, TAG 07:23:38 Brian Birtles, Mozilla 07:23:49 Emilio Cobos, Mozilla (observer) 07:24:19 Rob Flack, Google 07:24:21 Majid Valipour, Google 07:24:35 https://github.com/w3c/css-houdini-drafts/wiki/Berlin-F2F-April-2018 07:25:30 rune has joined #houdini 07:25:32 rune_ has joined #houdini 07:25:34 Topic: Typed OM 07:25:45 fremy has joined #houdini 07:25:53 Topic: Reifying style values 07:25:56 GitHub: https://drafts.css-houdini.org/css-typed-om/#reify-stylevalue 07:26:25 Loirooriol has joined #houdini 07:27:55 Oriol Brufau (observer) 07:28:03 TabAtkins: First issue is a quick review of reification and if what we have so far looks good. 07:28:11 TabAtkins: The general rule looks like [shows] 07:28:28 TabAtkins: Specific computed values are treated the same. You ask what the value is and reify it to a value. 07:28:35 TabAtkins: That's basically how they all work. 07:29:09 TabAtkins: Reification is making something into an object. Basically make the correct mapping type object. 07:29:24 TabAtkins: background-repeat is an extreme one because it has several forms. 07:29:57 TabAtkins: If you say repeat reapt it becomes repeat. IF it's more complicated it becomes 2 keywords. Else we send it as style value as a string. 07:30:04 emilio: The string it came from? 07:30:21 TabAtkins: Depends where drawing from. Spec takes the actual string, computed is serialized from 07:30:26 ??: Computed value or resolved? 07:30:29 TabAtkins: Actula computed. 07:31:01 dbaron: Are you requiring...specified values maintina some state but not all about spec. How much are you specifying? The way current work there are something things normalized and some not. 07:31:16 TabAtkins: It's not spec so if there's details preserved great. I'm assuming can get author spring 07:31:34 dbaron: In many cases it's preserved in a value form and normalizes away some distrinctions. 07:31:43 ??: That's the case for blink as well. 07:31:50 TabAtkins: I know spec values retain color format. 07:31:54 ??: we do that 07:31:56 s/??/Rune/ 07:32:00 TabAtkins: The numbers in there are normalized. 07:32:15 emilio: The color case is a special case. When you spec and ID that's the only case we keep the string. 07:32:23 rune: I think that's the case with blink as well. 07:32:35 dbaron: But we wouldn't preserve if you spec 100.0 or 100.000 07:32:45 TabAtkins: So i need to have spec value serializations. 07:32:51 Rossen_: That woul d be good in css 07:32:55 dbaron: And needs research 07:33:08 TabAtkins: As long as I keep it on the level of recomputing it should be okay. 07:33:25 TabAtkins: I'm not trying to spec how the current apis work, just how a new one stringifies. I'll try to be close. 07:33:37 TabAtkins: I'll need to record that. 07:33:40 TabAtkins: Continuing. 07:34:19 TabAtkins: A bunch of things have a final cause. Plan eventually is extend the OM to eliminate these. Worse case it may be a value list. In many cases we should be able to have a more useful object spec to the property and the genral value shape. 07:34:37 dbaron: Question: Is that going to be basically fully backwards compat so new object has some style value behavior? 07:34:49 TabAtkins: Yes. only behavior is it stringifies to something with the value 07:34:52 dbaron: ype indicator? 07:34:54 TabAtkins: No. 07:35:18 dbaron: I think it prob nice in cases where you intend to change in the future to have a note in the spec so that people are aware of it for compat. 07:35:35 TabAtkins: We can note. It'll be most or all that fall to a complex value. 07:35:37 ACTION: TabAtkins Investigate specifying specified values 07:35:40 Created ACTION-869 - Investigate specifying specified values [on Tab Atkins Jr. - due 2018-04-16]. 07:35:55 ACTION: TabAtkins Add note about things planning to change, e.g. CSSStyleValue expansions 07:36:03 Created ACTION-870 - Add note about things planning to change, e.g. cssstylevalue expansions [on Tab Atkins Jr. - due 2018-04-16]. 07:36:07 TabAtkins: Still got a lot of cases to fill in. I've done 10-20%. Most are easy because they're number or keyword. 07:36:21 TabAtkins: There's one case with specified and computed as different. 07:36:48 TabAtkins: azimuth 07:37:18 TabAtkins: The computed value is simplier then spec value. IT can be keyword, angle or both as spec. As computed it's only one. This will be the case for other properties. 07:37:31 emilio: Differnet types of lengths? So computed and spec are same in OM? 07:37:33 TabAtkins: Yes. 07:37:56 TabAtkins: This doesn't care about what unit is used, that's CSS domain. All this says is whatever the value is turn it into an object. 07:38:32 emilio: Are engines supposed to preserve calc? Only FF does it afaict. Blink treats it as normal int, I believe. Does that need to be address. 07:39:05 TabAtkins: It's a bug, but a bug on the typed OM side. If you're not preserving the information it will jsut come out as a 1px length. We're just taking the value as it is. 07:39:31 TabAtkins: If this looks fine I"ll continue, if people have specific complaints or a property let me know as I do them. I'll continue this list and grabbing properties. 07:39:44 TabAtkins: Do we want prefixed properties in this list? 07:39:51 Rossen_: If you want the web to work 07:39:59 TabAtkins: Do we care enough that we want a spec way to deal with them. 07:40:07 Rossen_: Let's see how long we can go without. 07:40:18 gsnedders: I'd favor webkit prefixed that we've specced. 07:40:48 dbaron: Prob should write a section for spec authors about how to write new properties and hopefully new stuff follows those rules. I agree prefix we spec should be in here. 07:40:57 TabAtkins: Do we have a list? 07:41:02 gsnedders: I think it's across specs. 07:41:14 TabAtkins: Then can I request non-webkit browser let me know what they impl? 07:41:28 fremy: If you have properties like each other do you get 2x the object? 07:41:36 TabAtkins: Every time you request the value you get fresh objects. 07:41:38 fremy: Okay 07:41:57 TabAtkins: No object reuse. You can reuse them yourself, but it will always do fresh. 07:42:11 brian: how do we maintin going forward? 07:42:55 TabAtkins: Best for everyone to have a doc we maintain as a living standard. Also because everyone goes through one spot we can maintain. I'd prefer to handle it that way. A seperate doc. 07:42:57 TabAtkins: Is that okay. 07:43:01 ??: Yes. 07:43:06 qs/??/nainar 07:43:16 TabAtkins: Same is typed OM rules for serialization as well. Turning a style into a string. 07:43:31 TabAtkins: We're done with that topic. 07:43:40 brian: Can we add the defintion to typed OM? 07:43:49 The answer for -webkit- spec'd props seems to be -webkit-line-clamp [CSS Overflow] and -webkit-user-select [CSS UI] plus a whole load from [Compat] 07:43:54 TabAtkins: Yes, that would be good. Can you file a bikeshed for me? I'll put something in prop defs. 07:43:59 fantasai: So split into 2 doc? 07:44:09 TabAtkins: Not yet, but at some point we might. 07:44:34 TabAtkins: Point I wanted is maintain this list as a single unified list that we keep updating. Maybe not standards track, but as much as we can. 07:45:12 TabAtkins: Any further concens raise it now. Otherwise talk later. 07:45:21 Topic: Forwards-compat design choices 07:45:26 GitHub: https://github.com/w3c/css-houdini-drafts/issues/735 07:45:51 TabAtkins: One issue...a general issue with any attempt to design typed om is what happens when we change value space of a property. 07:46:47 TabAtkins: There are patterns we commonly do like when something is a list. There are things not handled well like changing a property from being a single keyword to something more complex. Which means...the question is hwo to handle reification. If it started simple and we reify as a keyword and it becomes more complex there's options 07:47:48 TabAtkins: Firs tis we maintaing compat. If it's simple it's a keyword and more complex it's more complex. When the single keyword isn't a special case it's awkward to handle. It would mean if you want to test if the weight value is spec is it' the keyword or the keyword set. You'd have to branch twice. If we know the final value it would be more complex. 07:48:26 TabAtkins: I think I can make it less complex in common cases. In the basic types the relevent accessor have a unique name and then when it upgrades is still has the accessor. 07:49:14 TabAtkins: If we start with font synth as a single value and then becomes a double it would be a keyword set with a .keyword property that reflects the single value that exists. That way any older code will continue working properly. Newer code can work more natively. 07:49:39 TabAtkins: Won't work always, but a lot of cases. Propobaly changes the accessor to .keyword and string to .string. .unit.value stays where it is. 07:49:55 TabAtkins: More basic cases like a hash token we'll add a unique value. 07:50:09 TabAtkins: Is that a good idea or do we accept that as we extend we'll have legacy things. 07:50:45 shane: Is there a combo where we could consider so the special object type extends. THis is the same trick sa the style mapping. That gives us the consistancy approach to a longer list 07:51:05 TabAtkins: Likely. What I like is if a property is keyword or numeric and people branch on type can still branch on type. 07:51:40 TabAtkins: Means a slightly weird object hierarchy and we can't do it on number...Well...math values ar emore complex. But strings or keywords subclassing keyword value class would be fine. 07:52:03 dbaron: I feel...there's compat risk. Also the risk that once a thing is upgraded that people will write new code that only works for old stuff. 07:52:12 TabAtkins: ExmpalE? 07:52:59 dbaron: You're writing new code tha tonly works with single keyword case because you forgot this property was upgrade. When the compat thing is a thing where you can handle the old values you're creating a risk that people will fall into the compat risk. 07:53:07 TabAtkins: True, but only way to handle is break old code. 07:53:09 dbaron: True. 07:53:46 dbaron: There might be an advantage to not having the compat for properties that weren't upgraded. So if a property starts as multi keywords there's an advantage ot not having single keyword available. 07:54:06 TabAtkins: That was my plan. If we know ahead of time something is complex it'll descend straight from style. 07:55:02 TabAtkins: That reflects on a 3rd option, similar to how Ana tried to handle this. Every value had a short named accessor that gave you a complex value of it. If it was simple you'd get simple, but you could also ask for hte complex form and if it existed you'd get it. 07:56:11 fremy: Other similar thing was a problem for c# browser. They solved that by when you add a value you give a list of all functions you expect and then as the UA you know all the values expected byt he author and if it's none you can return the css tyle value. You have context. It worked for c# brwoser 07:56:18 TabAtkins: You'd have to put that into the get method 07:56:30 fremy: i don't know if it's good design, but it's one way that works. 07:56:43 TabAtkins: I thought of that, but figured it was too much to write on every get call. 07:57:17 TabAtkins: So, taling this over. Best idea is when we have this sort of upgrade situation we should, if possible, make new complex type subclass whatever it was before, but only do it for upgrade situations. 07:57:52 fremy: Another thing we could do is when we make a breaking change we can make a priority like a .v2 if they don't have it they get the old scenario. 07:58:13 TabAtkins: That's true. THat's reasonable. I hadn't thought of the escape when we can't upgrade. 07:58:18 TabAtkins: Reasonable to people? 07:58:40 Proposed resolution: when we have this sort of upgrade situation we should, if possible, make new complex type subclass whatever it was before, but only do it for upgrade situations 07:59:21 RESOLVED: when we have this sort of upgrade situation we should, if possible, make new complex type subclass whatever it was before, but only do it for upgrade situations 07:59:42 emilio: How is clampping done in typed om? 08:00:09 TabAtkins: It's automatic. When it enters the style system clamping happens. If you try and set a negative value typed OM is fine, when it enters style system it's 0. 08:00:29 Topic: Which string type? - DOMString, USVString, or CSSOMString? 08:00:34 Github: https://github.com/w3c/css-houdini-drafts/issues/687 08:00:57 TabAtkins: Intro: I need to know what type of string to use. Everyone familiar with these three? 08:01:32 TabAtkins: DOM is just JS strings. USV string is that but you can't write unpaired surrigates. Only actual scalar values. CSSOM string is one or the other and the UA has to choose. 08:01:37 gsnedders: And it has to be consistant. 08:02:33 TabAtkins: The arguments. USV string, it's an actual string and DOM allows nonsense. But DOM is exactly what JS uses. Some browsers can naively handle a scalar value faster and cheaper under the hood. Servo does that. 08:03:08 TabAtkins: Earlier we as do USV and for browsers not doing that have a long. Dominic came in and said don't do that, we use DOM for everything except those that require scalar values. 08:03:39 TabAtkins: There was an argument on this on github between Dominic and plinss. [scrolls through github] 08:03:52 https://github.com/heycam/webidl/issues/84 is an open issue about whether the WebIDL spec is providing the right advice there 08:04:04 TabAtkins: So, do we wait for TAG? 08:04:32 plinss: We discussed in Tokyo. We dont have solid advice yet. Ther'es a plan to get JS people and webIDL people together, but no answer yet. 08:04:40 https://github.com/w3ctag/design-principles/issues/93 is the TAG issue on this 08:04:46 TabAtkins: For the spec, I can put an inline in the spec saying it's under contention. 08:04:55 Rossen_: You're saying it's one or the other. 08:05:16 Rossen_: Right now it's CSS string and if the tag narrows down we'll align. 08:05:24 TabAtkins: I can go with that. Change everything to cssom string. 08:05:32 Rossen_: Yeah, it's pretty much what we do. 08:05:49 astearns: But with the inline note saying we're hoping less vague. 08:06:24 TabAtkins: Prop: spec goes with CSSOM String with an issue saying this is discussed by TAG and should resolve in the future 08:06:30 Rossen_: Obj or opinions? 08:06:45 plinss: Anyone with good info on this issue to help TAG it would be good. 08:07:05 emilio: If we change to DOM String it makes the private style system build a non-strandard string which is annoying. 08:07:20 fremy: It would be a mess, switching to surrogate pairs. 08:07:27 RESOLVED: spec goes with CSSOM String with an issue saying this is discussed by TAG and should resolve in the future 08:07:41 Topic: Which Workers to expose to? 08:07:46 GitHub: https://github.com/w3c/css-houdini-drafts/issues/632 08:09:00 TabAtkins: Currently we spec that all typed OM objects are exposed to all worker types because why not? It was brought up by the tag why do that we should restrict to those needed. Fine with that, it's just if we need some in the future we have to edit the spec. No reason to disallow because only big contention is not all context can access the CSS parser. It's only a few things allowe din arbitrary context. 08:09:11 dbaron: THings aren't on workers unless you can get to them there? 08:09:22 s/THings/I think the norm is that things/ 08:09:31 TabAtkins: Yeah. Reasonable argument. If there's a general policy of on't expose unless there's a reason I'm happy to. 08:09:37 dbaron: They're only on window and worklets. 08:09:39 TabAtkins: Yes. 08:10:12 dbaron: Is it...the other question is if it's exposed on all worklets or just painr worklet and if there should be a base class of all css worklets so we can expose that without interfereing. 08:10:23 iank_: TypedOM we spec we need a workflow. 08:10:29 TabAtkins: We can make a css type fast. 08:10:32 fremy: [missed] 08:10:45 TabAtkins: No, they're not a postable type. There's nothing that prevents us from making it postable. 08:10:52 fremy: If you can send into a worker, that's a reason. 08:11:09 TabAtkins: People would obj to them being in post without a use case. 08:11:39 iank_: Only medium temr thing use the typed OM is the canvas APIs. The font accepting a font query value. But we could expose that if canvas accepts it. 08:11:45 TabAtkins: We can wait for a use case 08:11:58 TabAtkins: Happy to resolve to restrict to just window and css worklets for now. 08:12:48 shane: It does seem to extract tht we're going to great lengths to differentiate worklets. Through impl details the same APIs behave differently accross workers has been a pain. It's a tiny thing that comes back to bite you. 08:13:00 shane: Do we really want to make them all look different? 08:13:10 dbaron: Many platform core APIs are sinlge thread. 08:13:35 shane: I get having the main thread be distinguished. But this is about workers. 08:13:55 dbaron: There are some APIs that distinguish dedicated, shared and service worker. 08:14:15 shane: Is the question do we need to distinguish these workers by the presence of this API? 08:14:43 dbaron: I don't know. WOuld be interesting to talk to JS folks about performance and complexity. It feels good you can only access useful things, but I don't have strong feelings. 08:14:56 shane: I don't have strong feelings, I wanted to do a counter point. 08:15:12 cbiesinger: Do we have the parsing restricted? 08:15:35 TabAtkins: Yes, it's restricted. You can construct values but you cant' use the parsing to do it. 08:16:08 TabAtkins: I still think for now restrict to just window and css worklets. If the discussion tends to being freer with worker exposed APIs we can change in the future. 08:16:29 krit: Note it may change? 08:16:31 TabAtkins: Yeah. 08:16:35 Rossen_: shane you okay? 08:16:37 shane: Yes 08:16:40 Rossen_: Obj? 08:16:52 RESOLVED: restrict to just window and css worklets 08:17:02 Topic: Approve URL handling/design 08:17:44 smfr has changed the topic to: https://github.com/w3c/css-houdini-drafts/wiki/Berlin-F2F-April-2018 08:17:57 TabAtkins: The core issue is the URL function in css has many types. These types are not distinguishable at parse time. Like mask image you can't tell if URL is a reference to a mask or a URL. The things we want to expose when reifying on these are different. 08:18:52 TabAtkins: Because previous resolutions on how to handle these I can't tell at time you ask for property what concrete type a URL should become. Reasonable in the future more cases will be ambig. If we let you refer to an SVG gradient URLs as an image might be a referenc to SVG gradient. 08:19:32 TabAtkins: My proposal to handle this is always reify the URL fucntion to a CSS URL class that exposes basically nothing. Maybe just loading status. Then have some methods like asImage that returns a promise for an image type. 08:20:12 TabAtkins: If you use image fucntion we know it's an image. In general you get this featureless things and you hav to ask. Only way around is to revisit the previous resolutions about making URLs a fragment which we rejected. 08:20:42 TabAtkins: If there are better ideas I'd love to see them. OTherwise I think we'll have to go with an approach like this. Or we have to go back and revisit to let URL types be parse time knowable. 08:20:54 krit: There were multiple discussions on how to do it at parse time. 08:21:02 TabAtkins: It was always based on fragment or not. 08:21:11 krit: For fragment you could put a fragment on an image. 08:21:54 TabAtkins: Absolutely. The way around was you have the image function to say this is an image no matter what the URL looks like. If that doesn't get wha tyou want you have exit clasuses. 08:22:14 krit: Required for author to know what type if has or but both on and look for which promise returns? 08:22:19 TabAtkins: Yeah, ask for both. 08:22:26 astearns: Or ask for the one you know what to do with. 08:22:44 TabAtkins: You could have something that gives you what type it becomes in the end. 08:23:05 smfr: Should we have a longer term plan to spec functions that are tied and deprecat URL? 08:23:33 TabAtkins: I would like that. Image is already stronger then URL. There are a small number of other types of URLs we take. Like fonts. 08:24:03 TabAtkins: If we impl image and encourage it's use that would elimintate a lot of issues. If we go with the slightly awk when you use URL it would encourage image. 08:24:23 TabAtkins: Typed OM provides a reason to use iamge because it reifies immediately 08:24:34 astearns: Two proposls, one with multi promise and one with a single? 08:24:46 TabAtkins: NO, that's just details. Question is generic or revisit 08:25:16 TabAtkins: Does anybody think we should revisit the resolution about parse time URL deciding? 08:25:20 [silence] 08:25:42 TabAtkins: I'll go with the design I described. You'll see it when it's in spec. If anyone objects at that point or has a better way, let me know. 08:26:02 smfr: Should we have actions or issues to make instructions for references. 08:26:26 TabAtkins: We have image. I think for css value there's an issue already. 08:27:05 Rossen_: Obj to TabAtkins's proposed design? 08:27:14 RESOLVED: Accept TabAtkins's proposed design 08:27:38 Topic: Loading and absolutization timing 08:27:52 TabAtkins: CSS is currenlty vague. It happens at some point but we don't know when. 08:28:43 github: https://github.com/w3c/css-houdini-drafts/issues/716 08:28:46 https://github.com/w3c/css-houdini-drafts/issues/716#issuecomment-368659261 08:29:08 TabAtkins: Her'es my proposal ^ 08:30:07 TabAtkins: Has a URL attribute. It's either an absolute or a bare hash. If it's not a bare hash we'll use CSS ruels. Underlying value may not be absolutized, but when it reifies we turn it absolute. If you move a style from one doc to another it may be relative in the old way, but it's now absolute. 08:30:15 TabAtkins: I think that's what people want. 08:30:26 TabAtkins: When you contruct a value it's absolutized immediately. 08:30:32 dbaron: When is it bare hash? 08:30:43 TabAtkins: When you pass it in as a local reference. 08:30:51 TabAtkins: That's spec in the value spec? 08:30:56 plinss: It's a string not a URL? 08:31:06 TabAtkins: Yes, it's strictly spec that it's a string. 08:31:37 TabAtkins: Only controversy is the early absolutizing. Is that okay or shouldwe make it retain it's relativeness and better define when it stops being relative. 08:32:07 TabAtkins: If you want to manipulate the URL the URL spec requires an absolute value or a URL with a base. It would be harder for authors since it's hard to get the base. 08:32:24 plinss: Would it make sense to keep it as a relative URL but also expose it as a base? 08:32:52 TabAtkins: Possibly. In the current CSS if you use the OM APIs if you pull a reltivate URL and write it somewhere else it changes the base. 08:33:07 plinss: Are we allowing authors to rationalize it as a valid URL if they want to. 08:33:13 TabAtkins: Do authors want this? 08:33:16 plinss: Yes 08:33:30 TabAtkins: I doubt they do. When this occurs style sheets are usually in same folder. 08:33:45 nainar: If we're being more eager about absolutizing should that be in css as well? 08:33:46 TabAtkins: Pos. 08:34:12 birlets: I'm wondering if there's a cloning use case? 08:34:22 TabAtkins: But would people want to do that? 08:34:33 TabAtkins: I can come up with a reason, but it's a minority case. 08:34:47 krit: If you provide the bbase would you still get back relative? 08:35:14 TabAtkins: You have to know where the split happened. If impl want to preserve I can attach the original URL. But the core easiest to use should be absolute. 08:35:22 krit: I'm fine with it as a default. 08:36:08 plinss: I expect there will be use cases, like editor. In my experience any time someone tries to help me with URL they get in the way at some point. If it's distructive that's painful. If there's a way to preserve the original url. 08:36:17 dbaron: Seems like it's not crazy to have multi accessors. 08:36:29 TabAtkins: I'm happy to put on an original URL value. 08:36:30 s/multi/multiple/ 08:36:40 plinss: Should that but the URL 08:36:50 TabAtkins: All the DOM apis do absolute URLs. 08:37:04 TabAtkins: Prop: We accept this proposal but also expose the original URL. 08:37:10 dbaron: You could also expose base URL 08:37:11 Proposal is comment in https://github.com/w3c/css-houdini-drafts/issues/716#issuecomment-368659261 08:37:29 TabAtkins: That would have to be dynamic. Oh, base URL as this instant. I could do that. 08:37:41 dbaron: I don't know how useful, but if you're exposing a bunch of information. 08:37:43 Rossen_: Okay. 08:37:56 Rossen_: Suggestions, objections? 08:38:14 RESOLVED: We accept this proposal https://github.com/w3c/css-houdini-drafts/issues/716#issuecomment-368659261 but also expose the original URL and base URL 08:38:25 Topic: end 08:38:33 break: 20 minutes 10:19:20 RRSAgent has joined #houdini 10:19:20 logging to https://www.w3.org/2018/04/09-houdini-irc 10:20:09 Rossen: We don't penelize people running on an awesome device. If we do have to have penalties we have information about what we need to keep. Seems like the best compromise on both sides of the fence. 10:20:35 iank_: We can tentatively do that for now and see what happens. 10:20:45 Rossen: If we want a resolution, not just a tentative what does it mean. 10:20:58 Rossen: We can introduce and explicit cache which re-writes cache 10:21:04 iank_: I don't think we want that yet. 10:21:07 Rossen: Even better. 10:21:31 iank_: For now instances and layout children get nuked when we switch global scopes 10:21:48 smfr: why not new children and isntance on invokation? 10:22:11 iank_: I'm worried about performance. Invoking a constructor is a few ms each time. 10:22:26 iank_: Let's start with we nuke everything when switching global scopes. 10:22:57 Rossen: Only thing we're adding is that input are also new instances. 10:23:08 Rossen: smfr ? 10:23:40 smfr: I'd prefer the super clean APIs where everything is done internally. Authors won't be surprised. If we do anything else they will get confused. 10:23:51 iank_: Should we see if authors will get confused? 10:23:59 smfr: If you can find some that are fresh. 10:24:13 iank_: We can do an origin question and find out. 10:24:20 Rossen: Not per call? 10:24:24 iank_: Yep. 10:24:53 Rossen: Objections to the lifetime of inputs and collections is the same as the policy for worklet swapping? 10:25:03 RESOLVED: the lifetime of inputs and collections is the same as the policy for worklet swapping 10:25:23 topic: end 10:25:47 [schedule wrangling] 10:26:33
10:26:41 Return at 13:26 10:46:45 rego has joined #houdini 11:13:14 smfr has joined #houdini 11:17:07 dael has joined #houdini 11:28:55 Rossen: We're back 11:30:32 Topic: Review the LayoutOptions.sizing parameter 11:30:39 github: https://github.com/w3c/css-houdini-drafts/issues/747 11:31:09 iank_: This is...we had one layout option for the child display. This is one mode I think we should add that flips the type of sizing you default to 11:31:33 iank_: As I was building examples it's really nice if you don't have to worry about your size. block-like is handled for you. 11:31:51 iank_: Like in my earlier demo you're always given a fixed size and you're given an auto block size. 11:32:10 iank_: Thing that makes it more custom is a manual sizing mode where you explicitly say the sizing. 11:32:31 iank_: If we use block-like initially it makes it a lot easier on impl to do it this way and less compat risk. 11:32:39 iank_: Is there any feedback? 11:32:51 smfr: Minor objection ot size as a word since it's height and width 11:32:59 iank_: This is the engine taking care of the size 11:33:03 smfr: But it's a scalar. 11:33:20 dbaron: CSS is using block-sizing already 11:33:31 smfr: What happens with a disctionary of auto block size? 11:33:39 s/block-sizing/block-size/ 11:34:07 iank_: In block-like it takes care of it for you. In some circumstances you'll get a fixed size like abspos and you're constraining the block. 11:34:31 iank_: I think for compat risk we'd want block-like as a default. 11:35:13 Rossen: This sounds more like native layout. Sizing and positioning are parts of layout, but you're not talking positioning. Engine for layout more for native layout mode or something like that for the name. 11:35:47 Rossen: Instead of 'sizing' to imply I want you to do layout on my behalf and the type of layout is block0like. 11:36:02 iank_: It's not simply layout. It's also the size of your fragment. 11:36:13 iank_: That's why I sort of.... 11:36:24 Rossen: ...Okay. 11:36:32 iank_: I'm fine calling it something else. 11:36:38 Rossen: I see what your intention was. 11:36:57 iank_: With this sizing is block0like it's computed as if you were a block container and that's pre-computed. 11:37:09 Rossen: So if you happen to be a flex item all the flexing will be ignored? 11:38:08 iank_: If you're a flex-item the engine can work out ahead of time what your size is going to be. If there's flexing that fixed inline size will be increased by the flex amount. Inline synthesis is handled by the engine and all you need to do is the flex size and that follows the same rules as the block size. 11:38:43 Rossen: I guess it's okay 11:38:53 iank_: You lose a little bit of power 11:39:31 iank_: It also allows if we're defaulting like servo can do it's inline sizing pass at the moment. From what I've used it's much easier and a lot less work. What it gives you is what you want 95% of the time. 11:39:57 Rossen: Was this edited in? 11:40:01 iank_: Yes. 11:40:10 Rossen: Objections to accepting this new parameter? 11:40:17 RESOLVED: Accept the new parameter in https://github.com/w3c/css-houdini-drafts/issues/747 11:40:37 Topic: Naming 11:40:44 github: https://github.com/w3c/css-houdini-drafts/issues/748 11:41:06 iank_: One feedback from trevors at TAG found it not saying border-box confusing. 11:41:10 dbaron: Yeah. 11:41:47 dbaron: As someone that works on layout code I'm used to knowing you have to work with border-box and you don't type it. Travis was looking at it further away from layout and he found it confusing. 11:42:11 dbaron: I lean toward disagreeing, but if we change it should be sizes and positions 11:42:14 iank_: Agree. 11:42:30 iank_: Unless webdev are really confused I'd lead toward us being shorter here. 11:42:56 Rossen: If anyone goes to extent of understanding what layout fragment is I have a hard tim ebelieving that person would struggle. 11:43:21 plinss: It's just knowing the difference of border and content box. Then what about box sizes and what do you do. Looks like it's more clarity. 11:43:28 Rossen: Someone going through learning phases. 11:43:38 Rossen: Objections to no change? 11:43:46 RESOLVED: No change on https://github.com/w3c/css-houdini-drafts/issues/748 11:44:13 Topic: end 11:44:22 iank_: Any tag feedback we should discuss? 11:44:25 dbaron: Let me see 11:44:58 [discussion around next topic] 11:45:10 Topic: LayoutConstraints object - Are we ok with exposing information we don't have compat on? 11:45:17 github: https://github.com/w3c/css-houdini-drafts/issues/749 11:45:37 iank_: All engines have pretty good compat...what we'll pass through LayoutConstraints object... 11:46:37 iank_: When it's non-orthogonal writing modes we have pretty good compat on what we'll resolve inline % and block % to. 11:46:46 iank_: Problem is with orthogonal writing modes. 11:46:57 iank_: A few cases in the issue, we have nowhere near compat. 11:47:10 iank_: First example is what we resolve % to 11:47:29 iank_: Padding in this example is completely different on all engines 11:47:53 iank_: Not arguing about who is right, I made lots of test cases yesterday and they're very simpl.e 11:47:54 iank_: plz make sure all these tests are in WPT 11:48:34 iank_: Do we want to get compat here first? Go back and not expose this initially and just use layout sizing as block-like? Are we fine exposing this knowing that orthogonal won't be common? 11:48:41 fantasai: I'm confused. Spec is clear. 11:48:46 iank_: No one follows spec. 11:49:09 dbaron: Seems silly to remove the feature for that reason. It should be clear what the spec says should happen in that case. 11:49:41 iank_: Half the comments on the spec...like Size with % size is one area of compat. For writing modes we only talk about available space. 11:50:06 dbaron: I think, it might be worth thinking about which thing makes the most sense in the API. Do you want the thing baesd on the parent's writing mode or your own? 11:50:22 iank_: It looks at everything in your own writing mode, but all engines have different conversion. 11:50:53 iank_: Here's a good example where % resolution for padding-left:10% varies. But the size you should resolve against isn't defined. 11:50:56 fantasai: Flexbox issue. 11:51:08 emilio: That was fixed recently in FF. If you test the nightly. 11:51:18 iank_: There's other cases here as well. 11:51:35 iank_: I'm fine with exposing all this, but it may be a while until we're toward compat. 11:52:21 iank_: Other option is strip LayoutConstraints and it's just the fixed layout size and the engine handles it's quirks for you. 11:52:34 s/it's/its 11:52:51 majidvp: Is there a way inside the worklet to detect UA? 11:53:01 iank_: Only if you pass in a property. 11:53:27 iank_: Initially given the state of compat I'd only feel comfortable exposing the simple layout and forcing block-like on everyone. 11:54:05 iank_: Keep in mind this is only input going in. For giving inputs to reach children I think we can reach compat there. 11:54:52 [silence] 11:55:23 dbaron: I'm not convinced that the compat problems are that severe. 11:55:42 dbaron: If houdini specs are clear what these things mean people impl the Hodini bits can be clear. 11:56:18 Rossen: You're saying code should work regardless of the inputs. If we need different inputs for different engines your code should do something right. It's to our benefit to work out compat bugs regardless of houdini 11:56:39 dbaron: Gecko has a data structure with this in the parent vs other have hte clind. If the speci is clear you can do the right thing. 11:56:55 iank_: Yes. Engines can give you different things for different stuff. 11:56:59 Rossen: So that's no change? 11:57:04 s/hte clind/in the child's writing mode/ 11:57:18 iank_: Yes. I need to write tests to make sure my interpretation is right. 11:57:32 iank_: Issue is not an issue. 11:57:50 Topic: Generator vs. Promise design for the API 11:58:03 github: https://github.com/w3c/css-houdini-drafts/issues/750 11:58:19 iank_: From the author PoV... 11:58:30 Rossen: The only difference is you added a * 11:58:40 dbaron: You need an async in the second line. 11:58:42 iank_: True. 11:58:58 iank_: These are the pros and cons [futher down the issue] 11:59:14 iank_: If anyone else has something to add here, I'll come back to the next meeting with data. 11:59:21 Rossen: Are generators broadly impl? 11:59:23 iank_: Yes. 11:59:38 iank_: Everyone does generators, though they haven't been used like this before. 11:59:48 TabAtkins: We won't expose the functions you can't run. 12:00:02 iank_: We'll have to make sure in the future. We have to code with eyes open. 12:00:18 fremy: You like this better because you can only allow some things to be sent? 12:00:27 iank_: It makes a tighter API. Promises are more familiar. 12:00:40 fremy: Dev are familiar with converting in the background 12:01:05 dbaron: After thinking about this, I'm feeling like the way devs interface with the engine here feels better desc by generator and not promise. 12:01:46 dbaron: I think because promises have this tie to an event loop thing where promises are running async on this micro-task. You're in the middle of this thing in the layout engine and it needs to call you many times. 12:01:52 ??: I agree you're generating the list 12:01:58 s/??/surma/ 12:01:59 TabAtkins: You're not though. We can call you fresh. 12:02:14 surma: That's details. Conceptually it works as a generator. 12:02:38 surma: I'm wondering if there's a place where scheduling with rpomises may become and issue and it wouldn't wiht promises. 12:03:04 fremy has joined #houdini 12:03:23 iank_: I think there's work in FF to work promises at the right time. For the syncronous engines we would all the layout engine, make sure task queue is exhausted, make sure we've got a promise. 12:03:38 surma: It makes more sense with generators even if it's 100% correct. 12:04:06 dbaron: I think one of the weird things about generator is it produces the last thing at the end. You're using yield and return syntax to do much deeper things. 12:04:49 TabAtkins: The yield at the top of the issue is not usefully yielding into the engine. It's saying do this layout and give me results. It's using a generator as an async iterator. It's possible, but not the preferred pattern. 12:05:11 TabAtkins: It off doing it's own thing. If it was synchronous we wouldn't have to do this. 12:05:27 surma: Both allow us to think about async and parallel layouts in the future? 12:05:31 iank_: Yeah. 12:05:43 Rossen: I'm hearing mostly people leaning word generators. 12:05:48 TabAtkins: No. 12:05:58 Rossen: Except TabAtkins. 12:06:18 iank_: We can also give two different versions and see what people expect 12:06:32 Rossen: TabAtkins would you object? Any objections? 12:06:45 TabAtkins: I have weak objection and would like wider review. 12:07:00 Rossen: Has there been review? TAG looked, did they say anything? 12:07:11 Rossen: I went through Travis's comments and they were high level. 12:07:21 dbaron: I don't remember this one. 12:07:37 iank_: I think notes from the TAG meeting are up. 12:08:02 [everyone hunts meeting notes from TAG] 12:08:28 dbaron: Minutes say "Travis: I have some review feedback to post to the issue." 12:08:35 dbaron: We came back to it the next day, though. 12:08:39 TAG minutes in https://github.com/w3ctag/meetings/blob/gh-pages/2018/04-tokyo/04-06-minutes.md 12:08:45 iank_: [skim-reads] 12:10:47 Rossen: There's a couple ways to get out. 1) We agree to adopt promise-based API 2) We stick with generators with a light objection from TabAtkins and then he can figure out if we should avoid it. If he comes back with reasons and we can change. 12:10:57 TabAtkins: I'll bother Dominic 12:11:09 Rossen: Sticking with Generators will force the discussion. 12:11:28 Rossen: Do we have people that object to promise-based APIs? 12:11:35 TabAtkins: Performance aspect 12:11:45 iank_: I want to do some benchmarking 12:12:02 iank_: I think layout will be particularly sensitive to bindings. 12:12:11 TabAtkins: My hope is we don't need to re-apply promises. 12:12:17 iank_: We might need special APIs. 12:12:26 iank_: I'll have everything hopefully done. 12:12:52 Rossen: Prop: We will continue adopting generators for layout functions. TabAtkins will followup 12:13:04 RESOLVED: We will continue adopting generators for layout functions. 12:13:18 Topic: Custom Pain 12:13:24 Topic: Custom Pain 12:13:28 s/pain/paint 12:13:42 Topic: ident vs. custom ident 12:13:48 github: https://github.com/w3c/css-houdini-drafts/issues/729 12:14:08 iank_: Currently it's spec as an ident. Except css-wide keywords like inherit. 12:14:36 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. 12:14:46 iank_: I don't think there's any reason not to. 12:15:10 leaverou: I opened an issue 20 minutes ago to say it was more readable if the ident was moved to the name. Does this interfere with that? 12:15:13 iank_: No. 12:15:21 iank_: Objections to keeping it as an ident? 12:15:37 Rossen: The person filing the issue was not here? 12:15:41 TabAtkins: Yes. 12:15:51 Rossen: Just curious if they have really strong opinions. 12:16:06 fantasai: If you start disallow and then allow nothing will break. 12:16:13 s/if the ident was moved to the name/if the ident was moved to the function name, so that instead of paint(foo, ...) it would be paint-foo(...)/ 12:16:29 TabAtkins: I doubt if it'll break. default is the only one that could be useful. 12:16:42 Rossen: Objections to keeping it as is? 12:16:54 emilio: No but I wouldn't object to changing either. It seems harmless. 12:17:25 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. 12:17:32 gsnedders: I'm also mildly in favor. 12:17:41 Rossen: How mild? If you object let's discuss. 12:17:44 gsnedders: I don't care. 12:17:51 RESOLVED: Keep the spec as in 12:17:56 s/in/is 12:18:06 Topic: JS export vs. registerBlah 12:18:16 github: https://github.com/w3c/css-houdini-drafts/issues/564 12:18:43 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. 12:18:58 iank_: Should we allow this in the spec? 12:19:40 surma: My reason was you can build tha ton the API we exposed. 12:20:01 surma: This seems more dev convenient, but I'm not sure how much they would experience the convenience since everyone is bundling. 12:20:12 surma: I think this is nice, but not worth the effort. 12:20:29 iank_: I think it's a bit of work for us. We don't have the onfirmation immediately exposed. 12:20:56 surma: Amy assumption that you can dynamically import and then tryand do exports, but if we don't have that you can't do it. 12:21:15 iank_: Do you think web dev coming to these APIs would expect...this is the first time an export could register 12:21:39 surma: We have used them, like the register call, which is not what I've seen in other APIs 12:22:09 dbaron: This may depend on how people persceve using them a couple years down the road. People who follow echnea script closely may have a better sense. 12:22:25 s/echnea script/ECMAScript/ 12:22:44 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 funciton I'm not here. 12:23:12 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. 12:23:48 iank_: Good point. Some oe fhte custom paint scripts we've seen people using it in the main winfow and the worklet. You can catch exceptions of registerPaint. 12:23:57 majidvp: Can you throw exception when you xport? 12:24:04 iank_: You can throw a global. 12:24:21 dbaron: Also search for where the function is. If it's export syntax I'm not sure how easy. 12:24:43 s/search for where the function is/you can search for the registerPaint name to find out what it does/ 12:25:02 plinss: If we allow export we have to ad dmore clarity. You need another class to indicate this is a worklet. A bare export is really dangerious with extensible concerns. 12:25:14 iank_: It seems like an idea we'll keep for later if this becomes common. 12:25:18 Rossen: Sure. 12:25:36 flackr: Other way is at the point you add a module, naming the things you expect to be exported. 12:26:04 Rossen: Objections to keeping the current design? 12:26:11 RESOLVED: Keep the current design 12:26:20 Topic: Make paint invalidation non-normative or something? 12:26:30 github: https://github.com/w3c/css-houdini-drafts/issues/447 12:26:58 iank_: Pointed out by Alan Jeffrey that...basically we have a section of the paint spec that says how invalidation works. 12:27:59 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. 12:28:01 iank_: Thoughts? 12:28:20 iank_: We could make this non-normative and say you can do validation this was or rely on caching step. 12:28:39 dbaron: I have a valgue memory when I looke d awhile ago I thought this section was more complex then it needed to be. 12:29:09 iank_: Maybe. I think I changed it since then where we moved the invalidation to individual pain functions. [reads] 12:29:42 iank_: WE could drop this and let the engines do smarter. Or make the whole section non-normative saying that engines can add incalidation. 12:29:57 shane: It would be much faster [missed] 12:30:19 Rossen: Leaning toward making it non-normative? 12:30:37 iank_: I'm fine with that. I think it should still be in the spec because I think engines will do that. 12:30:48 krit: Is there something we should add to ensure that everything is correct? 12:30:52 iank_: We did that. 12:31:00 smfr: The invalidation isn't exposed. 12:31:02 iank_: Yeah. 12:31:18 iank_: as a webkit engine impl your thoughts? 12:31:34 smfr: I don't think there's value to this section. Is there other text that spec when something becomes invalid? 12:31:37 iank_: No 12:31:52 smfr: You need that. You need to desc imputs that trigger 12:32:10 iank_: We've got that in the cache step. The paint size and similar. 12:32:33 Rossen: Objections to dropping section 2: paint invalidation ? 12:32:49 rESOLVED: drop section 2: paint invalidation 12:33:01 Topic: callback interface vs. not 12:33:09 github: https://github.com/w3c/css-houdini-drafts/issues/743 12:33:56 iank_: We built to be consistant 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 consistant with custom elements. 12:34:39 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. 12:34:56 iank_: I prefer the system we've got for consistency and it's slightly faster. 12:35:20 majidvp: One of the problems with current spec you use the functions but it's the webIDL pattern. 12:35:48 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. 12:35:54 majidvp: Can you make a callback interface? 12:35:57 iank_: Yes. 12:36:10 majidvp: I rememebr some warning in webIDL that you can't construct one. 12:36:37 iank_: There's now a section in webIDL spec [looks for it] 12:36:59 majidvp: A callback function can be a callback interface? 12:37:40 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 makeing sure incumbent realm is correct. 12:37:54 iank_: It's fine if we go with that. Callback interface vs not is the question. 12:38:08 iank_: I'd prefer as-is to be consistent with custom elements. 12:38:20 iank_: Unless there's a really good reason why we shouldn't. 12:39:45 iank_: Here I think sticking with what we have may be a performance hit based o nhow many times we're invoking the function. 12:39:52 iank_: I'd prefer to keep as is. 12:39:57 TabAtkins: I'd prefer caching 12:40:27 iank_: We can also, assuming we code....you can wrap the behavior as well. 12:40:39 brian: Can you re-register? 12:40:55 iank_: You can't re-register but you can wrap it up and re-call it. 12:41:15 Rossen: Anyone think we should not keep the current design? 12:41:23 iank_: We'll need to make some small changes to align. 12:41:32 Rossen: Objections to keep the design as-is? 12:41:44 iank_: Do we need to resolve to make changes to use webIDL? 12:42:10 RESOLVED: Keep the design as-is 12:42:26 RESOLVED: Conform to webIDL callbacks in the spec 12:42:51 Topic: end 12:43:02 iank_: I think that's all I have on Paint 12:43:13 Rossen: That's all that was on the wiki 12:43:28 Topic: Rename paint(name, args) to paint-name(args) 12:43:56 Topic: end 12:44:11 Topic: break 12:44:21 Resume at 15:00 13:01:37 smfr has joined #houdini 13:02:33 ChrisL, cc iank_ https://lists.w3.org/Archives/Public/public-houdini/2017Aug/0003.html resolution fpwd layout-api 13:10:26 Rossen: Let's resume 13:11:04 Topic: Animation Worklets 13:11:16 https://github.com/WICG/animation-worklet/issues/87 13:13:01 majidvp: Right now when you have an animation worklets 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. 13:13:13 majidvp: When it's stateful you need to go in sequence. 13:13:22 majidvp: Ask was to be able to make the distinction explicit. 13:13:37 fremy has joined #houdini 13:13:40 majidvp: Proposal from astearns was to have a state object. This is similar to layout API and caching property. 13:13:51 s/astearns/asajeffrey/ 13:13:55 (I think) 13:14:52 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. 13:15:10 smfr: Seems odd to have the state...Once you computed the state the first time you might want it to be read only 13:15:29 flackr: If you want that you should pass that in rather then computing it. i'ts a static input. 13:15:34 shane: Is that too restrictive? 13:16:12 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. 13:16:52 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 conservitive and if there are use cases we can relax. 13:17:14 flackr: Only concern with relaxing is detecting the state change. You have to detect or have an API to say I changed. 13:18:02 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 13:18:23 smfr: isStateful is a better description the hasState 13:18:51 majidvp: Current proposal is if the state object exists it means it's stateful, not sue isSateful or hasState. 13:19:00 smfr: Can you show us the API? 13:19:09 majidvp: First argument to the consctructor. 13:19:49 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. 13:20:00 majidvp: You can hold onto your state. 13:20:08 birtles: You look at length of constructor funciton? 13:20:46 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 13:21:11 majidvp: It's only when you register the animation. First time you're called it's null, as we animate you can change. 13:21:31 birtles: If you're looking at length of constructor I understand that, but how do you know. 13:21:46 majidvp: You're looking at spec, this is a proposal. You get the state and the options. 13:22:05 birtles: The difference between an animator and a pure animator is clear to anyone that works in React. 13:22:15 shane: It's an import and distinction too. 13:22:26 shane: Maybe an flag is acceptable 13:22:54 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. 13:22:58 shane: Can you clear state? 13:23:00 majidvp: Yes. 13:23:28 shane: This would be useful with impl a state machine. You can make a decision about what the next animation is. 13:23:40 birtles: What if you have several frames at ones and one is stable. 13:23:59 shane: You're stateless if it's many frames. If one frame is stateful it stops there. 13:24:31 majidvp: The example from Jan. they run in parallel and if they see state they can't treat it the same. 13:24:49 birtles: They're saying it's not impl-able. You're either stateful or stateless, choose one. 13:25:13 majidvp: Personally I'm fine for it to be static. Most of the use cases weren't specifically stafefull or stateless, but it did change. 13:25:30 flackr: Let's say we go with something static now, how may it change? 13:25:54 shane: If you register yourself as stateful or stateless you can register yourself as auto and change. 13:26:07 flackr: Right thing to do is statis route until we have feedback. 13:26:14 majidvp: iStateful is the proposed name? 13:26:19 smfr: Yeah. 13:26:31 shane: Do we want State or Stateful? 13:26:43 majidvp: It would be a static property on the animator class. 13:27:03 birtles: In the current spec you ask to register a function and that will change you pass something else? 13:27:05 shane: It should be enum values so it's extensible. 13:27:41 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 13:28:02 birtles: I'm wondering if we can just look at functions 13:28:28 majidvp: My understanding is that there is slighly different syntax for stateful and stateless. If you're stateful component it's a class. 13:28:48 majidvp: I think in this case static attribute on the class seems usable enough 13:28:52 shane: Makes it explicit 13:29:06 majidvp: There's nothing like this on other spec where we can extend 13:29:35 Rossen: What did we narrow down tp? 13:29:51 Rossen: Do we keep going with isStateful? 13:30:20 majidvp: I think it was have explicit attribute on the class, I don't know what hte name should be. If you want an enum stateful isn't a good name. 13:30:42 majidvp: An enum is the right idea, I'll bikeshed the name on the issue. 13:31:07 Rossen: WE want to have the state state on the class, name pending bikeshed. 13:31:12 Rossen: Objections? 13:31:28 birtles: I'd like to look at other options. I'm not 100% sure we need the attribute. 13:31:45 shane: If we want to preserve possibility of switching we need it. 13:31:56 birtles: I think there's more enquery to do. 13:32:26 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. 13:32:46 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. 13:33:04 Rossen: Objections to not having a dynamic ability on animations, they're either stateful or not. 13:33:16 RESOLVED: not have a dynamic ability on animations, they're either stateful or not. 13:33:27 Rossen: Do we need to expose this is the next question. 13:34:18 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. 13:34:45 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? 13:35:32 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. 13:36:27 majidvp: It's more obvious when anmation 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 seq. You're losing some performance benefit. 13:36:49 majidvp: Our impl doesn't run in parallel. 13:37:05 Rossen: By construction you're impl will know if it's stateless or stable 13:37:18 majidvp: How would you know. 13:37:27 smfr: Pasing state in constructor. 13:38:08 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. 13:38:13 flackr: How do you construct it? 13:38:16 Rossen: You tell me. 13:38:23 flackr: This was a static class to say. 13:38:49 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. 13:38:52 Rossen: Yeah. 13:39:21 majidvp: We have an opbect called options. We use it to pass things the animation needs to know. It's similar. I wouldn't mind that. 13:39:35 Rossen: That way everyone is kind of happy. birtles is happier. 13:41:51 RRSAgent has joined #houdini 13:41:51 logging to https://www.w3.org/2018/04/09-houdini-irc 13:41:57 Zakim has joined #houdini 13:42:00 Rossen has joined #houdini 13:42:08 gsnedders has joined #houdini 13:42:14 ChrisL has joined #houdini 13:42:30 florian has joined #houdini 13:43:32 majidvp: birtles proposal in the issue is nice and ergonomic. If it has 2 arguments it means second is tate 13:43:44 majidvp: Number of arguments. 13:43:51 Topic: Animation Worklets, continued 13:43:55 iank_: You can't look at the shape of arguments. 13:44:01 plinss has joined #houdini 13:44:01 Rossen: Your versioning becomes crazy. 13:44:14 birtles: It's common in JS libraries. 13:44:24 github: https://github.com/WICG/animation-worklet/issues/87 13:44:28 iank_: Are you switching inside of native code here? 13:44:59 iank_: When you call the register animation, you're looking for arguments, that doesn't work. That's not failable. 13:45:06 birtles: Call .legth 13:45:07 github-bot has joined #houdini 13:45:21 majidvp: If you call .length it gives you number of required params 13:45:30 gsnedder1 has joined #houdini 13:45:37 majidvp: If you have opional parameters, in webIDL at least. 13:45:50 birtles: There's another option further down 13:46:05 majidvp: I don't think second is possible. Can you differentiate between class and function? 13:46:15 TabAtkins: No, class returns a fuction 13:46:22 smfr: I think check is constructbale? 13:46:27 majidvp: Any is constructable 13:46:35 gsnedders: Not in webIDL 13:46:41 majidvp: This is user provided. 13:46:53 birtles: Point I was trying to make is that we don't nec need an attribute. 13:46:58 gsnedders: then it does have construct 13:47:10 Rossen: Checking number of arguments is defined. You can check the length. 13:47:34 shane: I think there is a more desciplined argument about having it as a param because it's clear to people making the code. 13:47:47 birtles: I think it's quite intuitive to check the callback function 13:48:07 Rossen: One of the versioning schemas we have in our API is based on number of parameters 13:48:29 shane: It's a technique. But we're designing an API. It's bad design to change fundimentally different behaviors based on magic. 13:48:36 q+ 13:48:41 birtles: I hear you, but I see it so much I think it's idomatic. 13:48:49 a/in our API is based/in our ABI is based/ 13:50:02 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. 13:50:08 Topic: Animation Worklets, continued 13:50:09 q- 13:50:13 github: https://github.com/WICG/animation-worklet/issues/87 13:50:22 iank_: It works on top of the class, but if you extend something it doesn't work. 13:51:04 github-bot has joined #houdini 13:51:27 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 # arguments passed through. You use that to choose one behavior or another. As an engine I think you'll have a hard time. 13:51:44 shane: THe experiment from iank_ shows you can't do it at top level. 13:51:54 birtles: I'm not sure we want to decide now, it's discussion to have. 13:52:13 Rossen: One of the things...the whole discussion was do we need the attribute or not. 13:52:31 shane: Isn't going back to the issue likely to push it to the WICG? 13:52:36 birtles: We can take it offline. 13:52:45 shane: F2F is when we do things in person. 13:52:56 birtles: WEdnesday afternoon, then, during the breakout? 13:53:03 shane: You want to think about it more. 13:54:01 Rossen: Let's summarize. we don't want the attribute. To avoid that we can pass the info throught he param 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. 13:54:35 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. 13:54:44 FWIW, IRC bot issues: https://github.com/dbaron/wgmeeting-github-ircbot/issues/27 and https://github.com/dbaron/wgmeeting-github-ircbot/issues/28 13:54:50 Rossen: What do we want to do. Stay with static or number of param on construction 13:54:57 smfr: Two super classes was an option. 13:55:01 majidvp: We haven't discussed that 13:55:18 flackr: If statefullness defaulted to stateless when not spec you get behavior that you want. 13:55:27 majidvp: Which is a good default to have 13:56:01 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. 13:56:10 flackr: You could throw if there is no state. 13:56:23 shane: That would be okay....it covers knowledge. 13:57:09 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. 13:57:32 Rossen: Going forward if we discuss again and have something better we can re-discuss. But let's not lose the opportunity to resolve 13:57:45 majidvp: The super class if you want to allow dynamic it doesn't allow for that 13:57:51 shane: Not just a third class? 13:58:19 majidvp: Okay....you're using a heavy hammer for something that could be an attribute. Attributes are very common. 13:58:47 shane: If thre'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. 13:59:02 Rossen: You can always have a conversion function based on object data 13:59:21 majidvp: Okay...that's not bad. I buy having the state object as a super class and then have setters. 13:59:26 Rossen: Other opinions? 13:59:45 Rossen: Objections to introducing 2 classes as a mean to listing stateful and stateless types? 13:59:55 RESOLVED: introduce 2 classes as a mean to listing stateful and stateless types 14:00:14 Topic: Implementation status update and plans for origin trial 14:00:51 majidvp: Last F2F we commited to new direction for the API bringing it closer to web animation. We've gone ahead to have our impl match the new direction. 14:00:57 majidvp: I wanted to give you an update 14:01:27 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. 14:02:03 majidvp: We've also impl scroll timeline which is the ave for animation worklet to read and be found through scroll. That's been working well. We've been providing feedback to scroll time spec. 14:02:17 majidvp: Also working on compositor to allow control from a separate thread. 14:02:37 majidvp: All is working. Need to work more on performance and look for areas not fully optimized. 14:02:48 majidvp: Impl is buggy in some cases, but working on it. 14:03:40 majidvp: Future plan is polish API and stablize and run an origin trial. It won't be the full spec, it's a similier 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. 14:04:07 majidvp: Surma has been working with the API 14:04:47 surma: Here's the demo (requires Canary). I've been working with the new API. It was limited but got a lot of attention. 14:06:05 surma: First insight is majority of effects can be done with web animationrs and scrollType. That being said, it won't hold once you want to make things stick to a finger or animate in 2 directions. 14:06:44 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. 14:07:34 Rossen: Gist of the demo is? 14:07:43 surma: The header goes into the top bar. 14:08:31 surma: Awk 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' not necessarily nice. 14:08:53 surma: If you could get timeline of scrollbar you'd have to measure that 14:09:26 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 14:09:58 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. 14:10:20 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. 14:10:35 surma: Also because we can fall back to main thread we should expose where this is running. 14:10:47 surma: It may be in the spec. 14:10:56 flackr: It's not. NOt since we went to pure web animations 14:11:08 surma: Other APIs allow to propigate to worklets, would be nice here. 14:11:14 flackr: I think we have update options. 14:11:23 majidvp: We haven't done it, there's notes saying we could do that way. 14:11:57 majidvp: Similar to layout worklet and using other inputs. We should be able to come up with a solution for when you update. 14:12:21 majidvp: If there isn't any follow-up we can move on. 14:12:32 Topic: Request to move the spec from WICG to WG as FPWD 14:13:19 Rossen: What was the policy around moving out of WICG? Was to 2 major impl intention to impl? What were the requirements? 14:13:29 ChrisL: Was that defined by them or us? 14:13:34 fantasai: We didn't have rules. 14:13:54 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... 14:14:05 Rossen: I don't expect them to object to us working on something. 14:14:28 Rossen: Assuming there's no process hurdles, any objections to moving the spec under Houdini and going for FPWD? 14:14:38 Rossen: Has anyone read the spec? 14:14:44 [only a few hands raise] 14:15:12 4-5 people reviewing a spec not all from the same company is pretty good tho! 14:15:31 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 sep. repo 14:16:25 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. 14:17:02 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? 14:17:22 Rossen: I remember dino pushing back on this in Tokyo. 14:18:27 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. 14:19:19 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. 14:20:06 krit: Before this goes to FPWD it needs to have normative and non-normative text indicated. You should avoid things like branding witht he twitter example. Seems to be a short spec, not sure if it needs to be bigger, though. 14:20:51 Rossen: We have another option. We move the spec to CSS/Houdini repo and continue as an ED. We can 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. 14:21:09 majidvp: I knew FPWD is a good time to get objections. If there are major objections I'd like to hear them. 14:21:24 krit: FPWD also has intention that the group will work on the spec and test. 14:22:04 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. 14:22:13 majidvp: But I don't think that's a FPWD requirement. 14:22:40 astearns: We want to make sure no one obj to eventually impl and have an idea there is a schedule they will evenaluate. Moving to Houdini repo will get more eyes. 14:22:43 Rossen: Agree. 14:22:51 astearns: You are not a WG member. 14:23:01 majidvp: Correct. flackr is a co editor and he's a member. 14:23:26 Rossen: The spec has 3 editors and flackr is the only member. Stephen isn't a member of any group. 14:23:36 astearns: They're from a member group, though. 14:24:13 s/member group/Member org/ 14:24:14 Rossen: one thing at a time. First thing is to move the spec from WICG to CSS HOudini drafts 14:24:17 Rossen: Obj? 14:24:30 RESOLVED: move the spec from WICG to CSS Houdini drafts 14:24:46 Rossen: Do we have enough people that have reviewed to publish as FPWD or wait? 14:24:59 astearns: I think we need to address the little details like normative and non-normative text 14:25:40 birtles: One more details it has a dependency on scroll driven timelines. Should we move that over? 14:25:59 birtles: It's a more fundinmental piece and this has a enormous dependency. 14:26:03 fantasai: Seems reasonable. 14:26:07 Rossen: Who edits that? 14:26:15 majidvp: I think birtles is one of the editors. 14:26:20 https://wicg.github.io/scroll-animations/ 14:26:47 majidvp: It takes the timeline and it could be a scroll timeline. 14:26:50 birtles: It's normative 14:27:00 majidvp: Yeah. We use it, but similar to other timelines. 14:27:07 birtles: Maybe not necessary then. 14:27:53 Rossen: I don't see a reason why we wouldn't take it. 14:28:03 Rossen: This is you and some Mozilla folks birtles? 14:28:16 birtles: They're not really working on it, I'm not really either. 14:28:29 Rossen: Do we need to move it? 14:28:48 birtles: I'm suggesting we leave it. 14:29:32 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. 14:29:39 astearns: I think non-google editor would be good. 14:29:53 majidvp: If birtles can edit that would be awesome. 14:30:31 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. 14:31:17 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. 14:31:52 Rossen: Objections to adding birtles as an editor? 14:32:01 birtles: I'm not sure I can commit to the time. 14:32:11 birtles: Let me look into it. 14:32:38 Rossen: WE can discuss editors when we do FPWD and go from there. 14:32:49 Rossen: Second action was for you to move the spec. 14:33:08 majidvp: I've done the move to CSS before so I think I know how to do it. 14:33:26 Rossen: Last actionfor majidvp, address the feedback. 14:33:32 Rossen: Everyone else read the spec. 14:33:36 plinss: Short name? 14:33:47 plinss: css animation worklet? 14:33:54 majidvp: CSS Animation API? 14:33:58 Rossen: Sounds good. 14:34:17 birtles: Is that confusing with CSS Animations? 14:34:23 nainar: It sounds like Animations 14:34:42 Rossen: CSS Houdini Animation API ^-^ 14:34:48 nainar: CSS Animation Worklet 14:35:00 cbiesinger: Custom Animation? 14:35:10 Rossen: CSS Animation Worklet. Any objections? 14:35:18 RESOLVED: CSS Animation Worklet 14:35:29 astearns: We'll likely revisit at FPWD. 14:35:45 Topic: end 14:36:09 [schedule wrangling] 14:36:13 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 14:36:42 https://github.com/w3c/css-houdini-drafts/issues/751 14:36:49 Topic: Paint API 14:36:57 github: https://github.com/w3c/css-houdini-drafts/issues/751 14:37:03 s/cbiesinger/??/ 14:37:57 leaverou: I was suggesting that since the item with the first param defines what is bieng paited it should be part of the function name. So it should be paint-blah. It reads more clearly and separates it from the arguments. Current situation is very hard to read. It makes the thing being panted the ame level of it's parameters. 14:38:21 leaverou: I think besides the ability issue, it reads much more naturally. 14:39:40 TabAtkins: We decided against the approach back when we were diong var. THe property is --foo and tha var is --foo. This is similar. If you don't have a requirement to regirester 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. 14:40:22 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. 14:40:38 TabAtkins: But one person could have written variables file. The difference of authors applies. 14:41:16 dbaron: Another issue is readability and understanding a new feature you see in code. Witht he 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. 14:41:32 leaverou: Because it reads more naturally. YOu're saying make it unnatural so people re confused. 14:41:56 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. 14:42:17 TabAtkins: When we have custom functions in CSS you can have whatever names you want with a -- at the front. 14:42:57 fremy: I agree with the point it's tricky to parse. One argument I like is auto-completion is getting surpremicy. But I also don't like putting function in. 14:43:11 dbaron: If you want to fix the function you can do a nested function. 14:43:29 leaverou: If your paint takes functions that also have parameters you end up with lists. 14:43:52 astearns: I suggested that earlier in IRC which addresses having the function and it's elements at the same level. 14:44:11 leaverou: What if we came up with a syntax that doesn't have the nested param. What if it's a keyword. 14:44:49 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. 14:44:55 good luck searching for 'paint' though 14:44:58 leaverou: Can you imagine this argument in any other language? 14:45:16 TabAtkins: JS swallows the compat issue of user stuff and browser stuff being in the same place. WE stay away from that. 14:45:29 fantasai: None of the param to a function are attached to a name. 14:45:37 leaverou: In JS you can create your own functions. 14:45:46 dbaron: But not that you get an additional name. 14:45:58 leaverou: In CSS you don't have . notation so you can't do what JS does here. 14:46:01 TabAtkins: Exactly 14:46:09 leaverou: Only seperator we have is the hyphen. 14:46:28 TabAtkins: But it's not for separate origins thing. 14:46:49 (my suggestion for the minutes since I emoted it before) is paint(company-logo()) and paint(chat-bubble(blue)) a terrible idea? 14:47:08 Rossen: Alright. Any more arguments? 14:47:10 I wonder if the first could still just be paint(company-logo) 14:47:25 leaverou: What if it remains as an argument but it's separated in another way like a / 14:47:34 TabAtkins: We don't use / unless required by parsing. 14:47:50 astearns: And anything other then nested parans would be confusing. 14:47:56 It would mean you can't create a function that returns an ident, and use that to select the paint function you want. ^_^ 14:48:03 flackr: I also find it confusing because the thing you're defining is a class. 14:48:11 leaverou: That's impl detail to a CSS author. 14:48:35 fremy: I forsee it being used for [missed]. As a css author you only care what you give to the conic gradient. 14:49:06 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. 14:49:20 leaverou: The one parans give you more places for people to screw up. 14:50:02 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. 14:50:12 leaverou: might be better for people to think so if we continue in GH issue. 14:50:28 shane: I think same argument applies, this is the space where we come to agree. 14:50:34 TabAtkins: It was just brough today, though. 14:50:47 shane: Fair. But if we resolve it's not the end of the world we can revisit. 14:50:56 Rossen: True. We can look for a resolution. 14:51:05 krit: We have the paint function and a resolution for it. 14:51:22 Rossen: We want a resolution to not change so we can mark it in the issue. 14:51:34 Rossen: Before I call for a straw poll, any other closing arguments? 14:52:03 Rossen: I've heard so far strong reasons against changing and readability and usability PoV a preference toward hypenated. 14:52:28 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. 14:52:43 Rossen: Let's try to resolve by objection first. 14:53:20 Rossen: Would there be objections to not changing the Paint function and custom paint function registration 14:53:38 shane: Does anybody object to closing this issue no change? 14:54:02 RESOLVED: Paint function and custom paint function registration does not change. 14:54:23 Rossen: I would suggest continuing discussion on this. 14:54:26 Topic: end 14:54:57 nainar: Should any specs move to the next stage? If we can get timelines otherwise nothing gets done. 14:55:12 Topic: Spec status check 14:55:20 Rossen: CSS Box API 14:55:31 Rossen: This is in WICG? 14:55:33 https://drafts.css-houdini.org/ 14:55:39 Rossen: Spec list ^ 14:55:55 TabAtkins: 4 today plus properties and values are the only ones being worked. 14:55:57 Rossen: And worklets 14:56:07 Rossen: Layout API is currently a WD. 14:56:15 Rossen: No, it's not. 14:57:01 iank_: I think I forgot to change it to ED. 14:57:15 Rossen: Ready for FPWD on Layout API? 14:57:18 iank_: Yeah. 14:57:22 fantasai: We have a resolution. 14:57:28 gsnedders: We've resolved at least twice. 14:57:45 fantasai: Action was on ChrisL to publish back in August. 14:58:09 fantasai: iank_ Should have followed up, but I put it on your plate this morning. 14:58:26 dbaron: Is there an issue tracking system for publication? 14:58:30 ChrisL: Yes. 14:58:42 Rossen: So action is on ChrisL to publish this. 14:59:02 Rossen: Painting API 14:59:03 https://lists.w3.org/Archives/Public/public-houdini/2017Aug/0003.html 14:59:09 surma: I think it when to CR 14:59:14 Rossen: In 2016. 14:59:21 fantasai: Was it ever published in CR? 14:59:25 Rossen: No. 14:59:51 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. 15:00:44 Rossen: I will find your list, ChrisL and ask iank_ and/or shane to followup. DoC and Wide Review are missing. 15:00:54 Rossen: And then this can go CR. 15:01:05 Rossen: In the meantime no reason not to publish a new WD. 15:01:33 shane: Publish a WD, send it to the appropriate groups, and then request CR. 15:02:00 RESOLVED: New WD for Painting API 15:02:11 Rossen: Properties & Values 15:02:23 TabAtkins: Published late last year. I can check if there have been edits. 15:02:37 Rossen: So no reason for a new WD? Last publish was November. 15:02:41 Rossen: Typed OM. 15:02:54 nainar: Probably need a WD 15:03:11 TabAtkins: It needs a new WD. I may try and publish now and then do one after the edits from today. 15:03:26 dbaron: Some previous version links are wrong 15:03:41 RESOLVED: Publish new WD of Typed OM 15:04:00 Rossen: Worklets prob needs a refresher. 15:04:18 Rossen: Last publish was June 7 2016. Reason to not have a new WD? 15:04:25 Rossen: iank_ ? 15:04:28 iank_: nope. 15:04:37 RESOLVED: Publish a new WD of Worklets L1 15:05:05 ChrisL: I'm filling in the thing on the transitions and I'm noticing Houdini specs don't have abstracts. 15:06:15 Rossen: Font Metrics. Did we move this to WICG? 15:06:24 several: I don't think so 15:06:40 iank_: The November was dbaron fixing meta data. 15:06:53 Rossen: Is there a reason to keep this in Houdini or move to WICG? 15:06:59 astearns: I think we resolved to WICG. 15:07:05 Rossen: I think same is true for Box 3 API 15:07:17 Rossen: That's it. fantasai did you uncover anything else? 15:07:45 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. 15:08:03 dbaron: And I put the W3C IDs to the specs to make it easier. 15:08:27 Rossen: Any other housekeeping? If not we're done with the agenda? 15:09:34 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. 15:09:38 Rossen: Thank you so much. 15:11:04 Rossen: We are adjourned 15:14:42 plinss has changed the topic to: https://log.csswg.org/irc.w3.org/houdini/today/ 15:34:30 trackbot has joined #houdini 15:39:29 neteru has joined #houdini 15:44:09 hi 15:54:44 neteru has joined #houdini 15:58:02 i was here yesterday, i wanted to add that i have over 45 grievences with the deputies here 15:58:49 the officers that arrested me were ada county sherrifs , all three of them 16:21:37 neteru has joined #houdini 16:24:31 i have to go bak in in please repost my messages everywhere u possibly can, 16:25:24 the deputies have made my life hell in here, i have tried to hang myself two times 16:26:04 i feel that i have no hope even with all of the case being bullshit, 16:26:42 thet are ging to rail road me 16:27:36 nomatter what! this is idaho, they have double the sentencing standards 16:29:08 they have no oversight & do whatever they want 16:30:26 the deputies have just continuously retaliated against me, they have made it theyre duty to punish me because i had no drugs or alchohol, 16:31:05 i have over 45 grievences and thy dont give a fuhk! 16:32:29 the law library wont let me print stuff i want, they said i can print what they want, i put in a grievence and the pig says some bullshit about my case!!! 16:33:00 i fel like im in the 1800's!!! 16:35:41 i really dont know what to do i dont have a real lawyer, i payed a lawyer 250$ and he came for about a half hour & never returned!!! 16:36:03 gtg 16:36:51 ty 17:12:05 Zakim has left #houdini 18:10:31 hober has joined #houdini 19:28:40 rego has joined #houdini