09:37:53 RRSAgent has joined #houdini 09:37:53 logging to https://www.w3.org/2018/10/25-houdini-irc 09:37:53 ... well it's not compatible with you switch 09:38:00 bz: code that used to work will start throwing exceptions 09:38:31 TabAtkins: this is detailed enough to know what the direction will be. let me know you thoughts 09:39:18 RESOLVED: Make TypedOM compatible with future Array-like plans, per #825. 09:40:56 Topic: precision and rounding in layout API 09:40:56 Topic: Layout precision 09:40:57 github: https://github.com/w3c/css-houdini-drafts/issues/817 09:41:03 github: https://github.com/w3c/css-houdini-drafts/issues/830 09:41:38 iank_: I wanted to write down the problem clearly 09:41:52 Rossen has joined #houdini 09:42:06 ... as specced now, with availableInlineSize: 10.13, the internal representations in each engine will be different 09:42:17 ... I believe Blink/WebKit will be 10.125, Gecko will be 10.133, Edge will be 10.13 09:42:50 ... similarly, say that child is auto sized, the value that you will get out in JS will be 10.125 for Blink/WebKit, some ugly values near 10.33333 for the others 09:42:53 iank_: this is exposed right now 09:43:07 ... if you set width:10.13px on an element, and you call getClientRects, you will get similar issues 09:43:24 Some of the ugliness is something that we could fix (by going directly from fixed-point to double rather than fixed-point to float to double) 09:43:30 ... part of me thinks this is a non-issue 09:43:53 leaverou has joined #houdini 09:44:23 plinss has joined #houdini 09:44:55 iank_: the thing I worry about with rounding is that you'll get potential tearing 09:44:58 LEAVEROU !!! 09:45:01 ... imagine if you're doing a flexbox-like thing 09:45:06 ... where you're distributing available space between children 09:45:18 ... with the current API you won't get any subpixel tear, but if you round inputs and outputs you will 09:45:29 ... you'll have to define the whole layout tree working on rounded precision mode 09:46:55 eae: when you say rounding, you mean rounding to ints or to these values? 09:46:55 iank_: if you round to int values, going in and out of the engine, you might see tearing 09:46:55 ... if you're distributing some fractional space in a flexbox-like thing you can't do that 09:46:57 ... also you'd need to specify the whole subtree works in rounded int precision 09:46:57 smfr: what do you mean by tearing? 09:46:57 iank_: if you try to position the two fragments side by side, you'd get a gap 09:46:58 ... similarly, the second class there is if you happen to be distribtuing some space that wouldn't get a gap, the element might be smaller 09:47:32 bz: to be clear, the container being smaller than the elements is a problem anyway 09:47:32 ... even with floats 09:47:32 iank_: the conversion to the js float thing, it's still possible to get tears accidentally 09:47:45 ... but because the JS repr is high enough, converting from the internal fractional to JS to the internal fractional will result in the same fractional value 09:48:10 chrishtr: what about pixel snapping? 09:48:38 iank_: we only do that at paint 09:48:38 ... we don't pixel snap any of the layout 09:48:38 TabAtkins: yes we do 09:48:38 ... border widths e.g. 09:48:41 eae: borders are very special 09:48:46 emilio: device pixels 09:48:59 dbaron: there's a small class of things where you care about the with of the thing being the same across repeated occurrences 09:49:17 ... borders, column rules, probably line heights as well 09:49:17 ... but for most other things we don't do internal snapping 09:49:20 ... you round to internal repr then snap edges to the nearest pixels 09:49:42 iank_: the pixel snapping borders we can repr that value in the LayoutEdges object 09:49:45 bz: presumably this is snapped to dev pixels here 09:49:47 iank_: yes 09:49:59 chrishtr: Blink currently snaps to CSS px 09:50:00 eae: not really 09:50:12 chrishtr: in cases where the device pixel ratio is incorporated into zoom it's device pixels 09:50:17 ... long term intention is to use device pixels 09:50:35 smfr: someone mentioned pixel snapping in border would happen at layout time? isn't purely a paint time operation? 09:50:49 dbaron: for us it's a computed value time thing 09:51:20 Rossen: for us it's also style 09:51:21 ... it matters for lower values, 1, 2, 3, px 09:51:21 ... but over 13, 14px it doesn't really matter 09:52:27 dbaron: but it does matter for not getting the 1px gaps that you do the snapping before the layout calcs based on it 09:52:27 ... if you do layout calcs based on a non pixel snapped border, then snap it later, you'll sometimes get 1px gaps or overlaps 09:52:27 Rossen: so we'll do the layout with fractional border sizes 09:52:29 ... then snap during paint 09:52:29 dbaron: but you need to snap all the things next to that border during paint too or they won't line up 09:52:30 Rossen: no they won't 09:52:30 dbaron: then your system is more complex then ours 09:52:55 s/more complex then ours/different in more complex ways from ours/ 09:53:57 chrishtr: is the intention to spec the rounding? 09:53:57 iank_: no 09:53:57 chrishtr: or just things that UAs may do? 09:53:58 iank_: my preference is to allow the UA to do internal rounding to the fractional repr and back 09:53:58 ... main thing I want to avoid is the 1px tearing in alyouts 09:53:59 chrishtr: it should at least be said if the left/right edge of things are the same number, there should not be a tear 09:53:59 eae: can probably find a way to spec that 09:53:59 chrishtr: you'd have to say the rounding and layout is the same, and that pixel snapping at paint time preserves that consistency 09:54:00 iank_: yep 09:54:09 Rossen: does that work for you Simon? 09:54:09 smfr: yes I think so 09:54:35 myles_ has joined #Houdini 09:54:35 ... WebKit does some snapping of border widths as well 09:54:35 ... I'm trying to understand when you're laying out fragments iteratively, does the browser tell you how much space is left? a floating point input 09:55:40 ... with custom layout, call layoutnextfragment 3 times 09:55:40 ... each time an input is the remaining space? 09:55:40 iank_: no you need to do that yourself 09:55:41 ... so you'll have some available size, layout first child, subtract the size of it in the JS double 09:55:41 smfr: was concerned about the conversions between jS doubles and the quantized values internally 09:55:42 iank_: since it's handled by script it's always the JS doubles 09:57:43 smfr: trying to think of cases where the rounding woul hurt you 09:57:43 ... maybe comvining custom paint and layout 09:57:43 ... you ask for a certain with with double precision 09:57:44 ... then in paint ... 09:57:44 iank_: I think previously you've brought up trying to fit into the one fractional unit, and some engines will leave a tiny fractional unit over 09:57:45 ... in one you go into the next line, in another you'll have a skinny box for some reason 09:57:45 ... I think it's a super edge case 09:57:46 fremy: my impression is that the only case where this could be an issue is where you do the data sharing between custom layout 09:57:46 ... you could share with full precision, and on the other side of the API you'd get it 09:57:47 ... but I also don't expect this to be a problem 09:58:32 Found that the internal->JS->internal conversion is always accurate up to (10^15)px; at 10^16 there's a few rounding errors with Microsoft's precision. 09:58:33 http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6318 10:01:54 jiaAn has joined #houdini 10:04:11 smfr: as a data point, this same problem also happens in media timing values 10:04:11 ... currently they're all floating point, but there've been discussions about turning them into a rational type 10:04:11 ... they're trying to solve some similar way here 10:04:12 iank_: I think there's been talk in JS previously about having value types 10:04:12 TabAtkins: they're not ready yet 10:04:12 iank_: they've been vapourware for a while 10:04:13 ... but the intention would be to work in that fractional type 10:04:13 ... we shouldn't depend on that 10:04:14 ... could imaging a future where JS does get that fractional type, see if it's compatible to change to that 10:04:14 ... or otherwise add an option to opt in to it 10:04:17 fremy: this transformation is a rounding 10:04:17 iank_: it's a rounding to the fracctional repr 10:04:17 fremy: can we floor rather thatn round? 10:04:18 ... otherwise if you divide by 7, all your 7 column objects, you give them avail size / 7 10:04:18 ... then you have a layout where each gets the size they can. if each is rounded up, the sum will be bigger than 100% and you'll wrap 10:04:19 ... better to floor 10:05:08 ... you make sure the sum will all fit 10:05:09 TabAtkins: flooring starts loosing this internal -> JS double -> internal relationship more quickly 10:05:09 eae: you can have a situation where you have a lot of space at the end 10:05:10 ... which is also not desirable 10:05:10 fremy: people writing the layout will pay attention to this 10:05:11 smfr: has anyone tried using the prototpye to see if it's a problem? 10:05:11 fremy: the prototype is only in one browser 10:05:12 smfr: still possible to make layouts with hairline gaps 10:05:12 fremy: I've not tried but I guess it's possible 10:05:12 iank_: we can see if people run into it 10:05:13 ... so far surmar and fremy haven't run into it 10:05:17 smfr: your masonry layout wasn't trying to fit something into something with a border, not obvious there's a gap 10:05:28 iank_: we can experiment with prototypes with borders to see if we can get hairline gaps 10:05:29 fremy: grid has the opportunity to ahve these options, but you can position things at particular points, no wrapping 10:05:29 ... even with 7 column grids, you place them before sizing, so it doesn't matter 10:05:30 ... we should try the flexbox-like thing 10:05:34 iank_: I think the action item on us is to play with our impl to see if we can break 10:05:37 ... but sounds like people are relatively fine with the float repr and rounding to fractional units internally 10:05:37 ... we can report back to the group 10:05:40 futhark has joined #houdini 10:05:44
10:05:45 github: end topic 10:05:58 github-bot: end-topic 10:05:58 TabAtkins, Sorry, I don't understand that command. Try 'help'. 10:06:02 github-bot: end topic 10:06:36 github-bot: end topic 10:16:28 futhark has joined #houdini 10:28:41 futhark has joined #houdini 10:41:53 florian has joined #houdini 10:53:48 futhark has joined #houdini 11:03:23 myles_ has joined #Houdini 11:05:04 lajava has joined #houdini 11:09:41 Oriol has joined #houdini 11:12:05 jiaAn has joined #houdini 11:13:29 nhassan has joined #houdini 11:13:54 bz has joined #houdini 11:14:40 ScribeNick: TabAtkins 11:15:04 Topic: FontMetrics 11:15:32 koji: This is about issue 828 11:15:43 https://github.com/w3c/css-houdini-drafts/issues/828 11:15:50 GitHub: https://github.com/w3c/css-houdini-drafts/issues/828 11:15:52 github: https://github.com/w3c/css-houdini-drafts/issues/828 11:15:52 koji: Request from authors that want character advance information for each character of a string 11:16:01 arnog has joined #houdini 11:16:09 koji: In canvas API we once tried it, but it had lots of feedback, so this is a revised proposal. 11:16:33 koji: use-case is an author with a string, they want to know caret position for drawing between each pair of characters 11:16:40 koji: Or decorations on specific characters 11:16:56 koji: This revised proposal has a .character FrozenArray with TextMetrics, a new interface we're defining. 11:17:10 koji: Each TextMetric has metrics for one grapheme cluster 11:17:22 glazou has joined #houdini 11:17:33 koji: And has an index into the original string, by code unit 11:17:49 koji: Has advance, and a boolean indicating rtl vs ltr 11:18:11 koji: We've gotten some feedback on it already. 11:18:18 satakagi_ has joined #houdini 11:18:25 koji: From Myles: 11:18:55 myles_: When I read this I thought it was about caret positions, not grapheme clusters. 11:19:18 myles_: So is it one entry per grapheme cluster, or one per caret position? 11:19:28 koji: Ambiguous. Authors I talked to didn't understand the differences. 11:19:39 koji: You're right there's some subtle differences between those. 11:19:53 koji: As far as I understand the rquest, they often want the character, to draw decorations. 11:20:08 koji: Most webapps handle grapheme cluster as the minimum unit to apply stuff to. 11:20:36 myles_: It should be noted that there's a jquery plugin to get caret positions. 11:20:53 myles_: It inserts spans into the content and then gets client rects. 11:21:18 koji: I think in the long run, authors might want to different distinctions for those two. But for initial level, start with caret position. 11:21:27 myles_: So why not specific how ligatures work? 11:21:40 myles_: You say "the UA *may* produce one cluster for a ligature" 11:21:51 koji: Good point. 11:22:18 koji: Intention was, as far as we could tell, impls do slightly different things with caret positions there. 11:22:34 koji: There was feedback from someone else preferring us to say that it should match UA behavior. 11:22:45 myles_: I think that's reasonable. 11:23:07 myles_: If intention is to draw a background on a string, and it has an ﬃ 11:23:18 myles_: And if they want to draw it just behind the f... 11:23:42 dbaron: It seems like every UA has some behavior for carets in the middle of a ligature. 11:23:54 dbaron: I hope there's no UAs that totally put it off on one side. 11:24:06 dbaron: But even if the bheavior is different, it still seems we could expose what UAs do in that case. 11:24:18 smfr has joined #houdini 11:24:22 dbaron: So you'd have a more interpoperable behavior for the number of *entries* the dev would see in the array. 11:25:04 myles_: Right. We shouldn't *fully* specify because in some situations we divide ligature evenly by number of grapheme clusters, but that's not great. We do have a native API to give us correct boundaries, we're just not using it. I'd like the flexibility to get that. 11:25:24 koji: Right, like I said earlier, the return value should match what the UA does. 11:25:51 dbaron: Right. If you do "fix", I don't want some UAs to return two entries, and other get three, just because some don't provide inter-ligature information. 11:26:07 fremy: If you have emojis that are composed of multiple chars, this API then doesn't work. 11:27:03 myles_: If your string is "e", the result is two entries. First is the letter "e", second is the multi-char family emoji. 11:27:11 nhassan has joined #houdini 11:27:15 dbaron: And same for e + combining-acute-accent. Those aren't treated like ligatures. 11:28:20 myles_: The number of entries in the result is not font-dependent, is what's important here. 11:29:00 TabAtkins: What about regional-indicators? (flags) 11:30:08 myles_: If your font doesn't support flags, you get one grapheme cluster, it just looks like a pair of characters. 11:32:36 The next feedback to discuss is "Since the clusters will be in visual order, we should determine if It’s in the direction of the base direction or if it’s always LTR. (Internally, WebKit always uses LTR, and if the base direction is RTL we do some processing to flip it around so our internal visual-order data structures are always LTR.) I’m not arguing for one or the other; just that we need to specify which way it is." 11:32:51 myles_: This should be visual order, right? 11:32:59 koji: Request is to determine advance of source string. 11:33:07 koji: So in my proposal the char is in logical order, not visual. 11:33:28 myles_: I thought you said a use-case was putting a background behind part of the string, how od you do that if it's in logical order? 11:34:04 koji: By making chars in logical order, author can determine where each character is, then the author can process it themselves. 11:34:18 myles_: Does that mean at a fragment boundary you could get a really big negative advance? 11:34:23 fremy: This was part of my feedback as well. 11:34:29 fremy: Is the advance negative in that case? 11:34:46 fremy: If you want logical order, this needs to break across bidi, or use visual order. 11:35:09 myles_: The JS i18n APIs would probably be interested in adding some APIs for this if you really want it in logical order. But I think it would be best in visual order. 11:35:22 koji: This interface has ltr vs rtl, so author can control this somewhat themselves. 11:35:53 q+ once these current issues are finished 11:36:04 q+ to say something once these current issues are finished 11:36:16 TabAtkins: You need to know how many chars you're formatting to do visual order, right? 11:36:25 myles_: Right, you can only reasonably call this *after* line-breaking. 11:36:53 koji: So the consensus is to use visual order, and add number of code units for each TextMetric unit. 11:37:33 myles_: You may want both "codeUnitIndex" *and* "lengthOfCluster", since it's in visual order. 11:38:19 with https://drafts.css-houdini.org/font-metrics-api/#measure-api 11:38:20 myles_: Most important question I have is how you associate this call with a font. 11:38:31 fremy: There is the measureTExt function in the canvas api 11:38:37 myles_: Is this a new thing, or a repalcement? 11:38:46 koji: We want to sync this with the canvas api. 11:38:53 koji: We'll port this to canvas api once we agree on it. 11:39:13 heycam: So the FontMetrics API spec has a new, separate measureText function. 11:39:50 koji: Proposal is to add .characters to both FontMetrics and Canvas API. 11:40:01 fremy: So this is a mixin that will be used in both interfaces? 11:40:03 koji: Yes. 11:40:32 q? 11:41:00 myles_: Next feedback - unsure if this makes sense to run on an arbitrary element, since arbitrary elems can have children? 11:41:11 heycam: That's my question, yeah - what does the index count into? What about dipslay:none? etc 11:41:13 ack heycam 11:41:13 heycam, you wanted to say something once these current issues are finished 11:41:32 heycam: I think there are similar index issues with the string API. You have whitespace collapsing/trimming. Need precise definition of what indexes are used. 11:41:51 koji: I udnerstand that part isn't defined here. If we applied this to element.meausreText(), we have to define that. 11:41:58 koji: Currently the proposal only covers measuring a string. 11:42:05 koji: I'll work on a proposal to define the element case. 11:42:18 q+ 11:42:19 heycam: In SVG we have a silly character-positioning API, and it's pretty annoying. 11:42:31 heycam: If there was a way to avoid all that and just stick to strings, that would be nice. 11:42:44 myles_: So I'd like to propose removing the measureElement function. Just keep it to strings for now. 11:43:06 myles_: There's more complications, like letter-spacing and such. 11:43:23 heycam: And text-transform - one character suddenly becomes two grapheme clusters, etc. 11:43:57 myles_: Another way to do it is not take StyleMap, but just a small set of properties you want to handle, like font-family and font-weight. That's what the canvas api does. 11:44:09 myles_: You can't specify font-variation, etc. 11:44:27 heycam: Ultimately it depends on the use-case. 11:44:38 heycam: If they want to measure stuff in the DOM, but they can't measure everything, maybe not useful. 11:44:49 eae: Majority of use-cases we've observed are for out-of-dom measurements. 11:45:09 Rossen: So many things we could resolve on, lot of feedback. 11:45:17 Rossen: I see a request to remove measureElement(). 11:45:24 Rossen: We need to change order to visual. 11:45:29 Rossen: Add .lengthOfCluster 11:45:51 heycam: Define how whitespace collapsing, text-transform, etc that cause idfficult mappings between characters and clusters. 11:46:01 myles_: And change how ligatures and metrics interact. 11:46:36 krit: SVGWG is also looking at this problem for the counting part. At the moment svg1.1 says we should use unicode codepoints, that's not very consistent. In our investigation we found grapheme clusters aren't well-specified. 11:46:53 krit: There might be bigger issues. 11:47:14 myles_: Unicode *tries* to specify what grapheme clusters is. If that's insufficient, we have larger problems. 11:47:28 krit: We want there to be alignemtn between fontmetrics and SVG glyph counting. 11:47:41 myles_: We've been talkinga bout a number of things that need to change, but in general this is a good direction to go. 11:47:45 krit: Agree, very useful. 11:47:57 ack krit 11:48:26 Rossen: So please take feedback and reflect it into the proposal, we can discuss it over the issue in the future. 11:48:29 myles_: One more - 11:48:47 myles_: It seems totally reasonable for an author to want to use this api for things like caret positions as well as grapheme clusters. 11:48:58 myles_: I imagine this'll be extended to other segmenters in the future, so keep that in mind. 11:49:04 koji: Yeah, looking for opinions on that. 11:49:21 koji: Currently the proposal is to add an attribute, and if you want to add different segmenters, maybe make it a function? 11:49:31 koji: Or add other attributes that segment differently. 11:49:38 myles_: Will need time to think about it. 11:50:36 xfq has joined #houdini 11:51:00 ScribeNick: iank_ 11:51:08 koji: I really like how this doesn’t expose teh concept fo a glyph 11:51:40 glazou: Thanks for greg for starting document. 11:51:46 Topic: CSS parser 11:51:51 glazou: Like to compare contents to one liner of abstract. 11:52:09 glazou: 11:52:19 glazou: Can you build a pre-processor like SASS. 11:52:31 glazou: There is extra things needed like the additional SASS syntax. 11:52:41 glazou: I think we need to dive down into the lexer level. 11:52:48 TabAtkins: That is indeed was is exposed. 11:53:18 to be clear - this is the draft we're discussing - not the one in houdini: https://wicg.github.io/CSS-Parser-API/ 11:53:27 glazou: what about things inside {} inside a block? 11:53:47 TabAtkins: No inside a block 2 choices, 1) @rules and decls, 2) @rules and other rules. 11:54:00 TabAtkins: You need to tell the parser which one of those two modes. 11:54:09 glazou: If you want to do something CSS-like. 11:54:22 glazou: At this point we cannont, need to open this up a little more. 11:54:33 glazou: A little too high level. 11:54:40 TabAtkins: Want to expose the full token stream. 11:55:04 glazou: If we do that impl. a SASS engine, will be doable, and much faster than the CSS pre-processors. 11:55:22 glazou: We'll be able to ship SASS sheets to the end user, will be really useful. 11:55:29 TabAtkins: Yes - faster and more correct. 11:55:53 glazou: I still think exposing the lexer could be extremely useful. 11:56:06 TabAtkins: sure - can you file an issue? 11:56:30 glazou: The lexers are quite difficult, are you open to such a stardardization? 11:56:50 TabAtkins: That's basically the css-syntax spec, which many browsers have reimpl. on top of. 11:57:08 TabAtkins: Blink's parser is already close, as well as FF - I believe. 11:57:13 TabAtkins: At least servo's is. 11:57:21 emilio: We use the same, so yes. 11:57:37 Should be able to expose the token stream.... 11:57:55 Rossen: We are also improving ours to matching blink/servo's impl. 11:58:04 glazou: Are you open do exposing. 11:58:15 Rossen: Yes once we've moved closer. 11:59:21 gregwhitworth: Let's get a v1,v0 of access to the parser, i need to pasrse out the color, output is the typedom. v2 is the lexer issue. 11:59:48 gregwhitworth: I know there is a desire for custom @rules, you might not need that once we've get the lexer access. 12:00:08 TabAtkins: TypedOM api first, then parser... (describes dependencies). 12:00:18 glazou: I'll have a little more time to work. 12:00:30 gregwhitworth: You are referring to the WICG version of this? 12:00:33 glazou: ...yes. 12:00:47 Rossen: Ok sounds great, lets move on. 12:00:58 ScribeNick: TabAtkins 12:01:51 Topic: AnimationWorklet 12:02:00 majidvp: Wanna give an update on AnimationWorklet, I missed last f2f 12:02:05 majidvp: We've made good progress on Chrome iml 12:02:09 s/iml/impl/ 12:02:24 majidvp: Then a new interesting topic about inputs besides scroll to feed into, lots of interesting use-cases. 12:02:31 majidvp: So this is AW background. 12:02:47 majidvp: timelines are new, they feed time into the animation, at the end you get a style update 12:03:05 majidvp: WorkletAnimation is just adding a callback hook in the middle. 12:03:23 majidvp: So this lets you runs cript and have state, but you don't ahve to run on main thread. 12:03:31 majidvp: We run on different thread, so we can keep up with antive framerate. 12:03:35 majidvp: No jank! 12:03:51 majidvp: Last time we had a resolution on AW it was to migrate the repo, this has been done + all issues. 12:04:01 majidvp: Another major change was to differentiate between stateful and stateless animations. 12:04:13 majidvp: Stateless animations can pump frames in parallel. 12:04:20 majidvp: So spec has been updated to handle that. 12:04:40 majidvp: There was a destroy() to pull state out of an animation; now we have two classes, and Stateful animations are more ergonomic. 12:04:59 majidvp: Spec's been updated, impl is lagging so far, will catch up. 12:05:06 majidvp: Some demos... 12:05:59 majidvp: Animation here is *very* simple, just pushing currentTime into localTime for the animation. 12:06:13 majidvp: Most demos I showed are like this. 12:06:38 majidvp: We're able to do this for both composited and main-thread scrollign with no problem. Geting less nad less bugs filed by Surma, which tells me it's pretty stable. ^_^ 12:06:56 majidvp: Another update - initailly we only updated the "fast-path" properties, but WG didn't want that to be special. 12:07:00 majidvp: We have implemented that! 12:07:17 majidvp: This demo was previously transform, but now it touches 'width'. 12:07:41 majidvp: So it matches what you can do with WebAnimation 12:07:56 majidvp: Similarly we animate the fast-path properties on fast-path; slow ones happen on main thread. 12:08:08 majidvp: Another feature we took from WA2 is GroupEffect. 12:08:14 majidvp: We've exposed that inside of AW. 12:08:20 majidvp: Lets you animate multiple elements together. 12:08:59 majidvp: Doing an Origin Trial in Chrome71, to gather dev feedback on perf and ergonomics. 12:09:07 majidvp: Questions? 12:09:16 majidvp: A few more demos... 12:12:12 cool demos 12:12:19 majidvp: So new proposal. 12:12:30 https://github.com/w3c/csswg-drafts/issues/2493#issuecomment-422109535 12:12:37 topic: https://github.com/w3c/csswg-drafts/issues/2493#issuecomment-422109535 12:12:57 topic: [web-animations-1] Generalized Time Values and Timelines 12:13:06 github: https://github.com/w3c/csswg-drafts/issues/2493#issuecomment-422109535 12:13:44 majidvp: Early on we looked at things people needed for scroll, but we early knew we needed to solve the more general use-case of interactive animated effects. 12:13:57 majidvp: Mobile or touch-friendly interface, you see drag-and-drop, scaling/zooming/transforming etc. 12:14:01 majidvp: Touch-based interactions. 12:14:10 majidvp: Righ tnow only way to do this is with touch-event handlers on main thread and use rAF(). 12:14:19 majidvp: These are not time-based animations, just input-driven. 12:14:27 majidvp: Scroll-linked animations are a subset of these. 12:14:34 majidvp: Scroll is easier; it's 1d mostly. 12:14:48 majidvp: So you can map it to time, easy. And can use with WebAnim. 12:15:02 majidvp: Touch and gestures are more complex: not single-dimenstional, and are stateful. 12:15:13 majidvp: Almost impossible to do this declaratively in a way that's expressive. 12:15:24 majidvp: This is why people use the manual scripting approach on the main thread. 12:15:41 majidvp: What we want to do is use AW to handle these use-cases as well. 12:15:43 futhark has joined #houdini 12:15:59 majidvp: If we can pull this off, we can incentivize devs to move some critical UI rendering work off of main thread. 12:16:15 majidvp: It also lets browsers know it's an input-drive animation, so they can prioritize properly. 12:16:27 majidvp: We've all seen janky touch-based effects; it's very hard to pull off on the web. 12:16:40 majidvp: So if AW can handle these, it should help a lot with the responsiveness. 12:16:53 majidvp: And will have the same basic play/pause api we have for regular time-based animations. 12:16:58 majidvp: So a lot of goodness here. 12:17:11 majidvp: This is basically what we're going for scroll, but supercharged. 12:17:21 majidvp: Like to start with pointer inputs, you can do a lot of interesting things there. 12:17:27 majidvp: So why AW as a primitive? 12:17:38 majidvp: First it already runs off-main-thread. Designed so it can be stateful. 12:17:51 majidvp: And because it's JS you can express complex things that would be very hard to do declaratively. 12:18:00 majidvp: Main thing missing is having input other than scroll. 12:18:25 majidvp: We've been thinking about this for a little while. Initially thought we could fit everything into timelines; maybe multiple timelines for animations. 12:18:46 majidvp: I chatted with Brian and Antoine last time, and realized model doesn't work well. Multi-timeline doesn't fit well with animations, too complex. 12:19:36 majidvp: I think our new appraoch is reasonable. 12:19:46 majidvp: AniamtionInput is separate from AnimationTimeline 12:20:14 majidvp: But touch animations can have multiple effects: pointer-input, scroll-input, etc. 12:20:46 majidvp: More complex scroll too - 2d scrolling, maybe active scroll or momentum. Maybe know that finger is down, even if not actively moving. 12:21:02 majidvp: So this keeps timeline simple, focused on that use-case, and then have the wider thing. 12:21:16 majidvp: I want to build this model so later if there's a gesture exposed, maybe we can get access to those. 12:21:28 majidvp: Also want to make sure that you can listen/unlisten to a given input. 12:21:36 majidvp: Passively monitor something without it actually ticking you. 12:21:45 majidvp: Conceptual diagram: 12:21:53 majidvp: [on screen] 12:22:01 majidvp: This is the high-level IDL: [on screen] 12:23:04 majidvp: Example of PointerAnimationInput [on screen] 12:24:03 majidvp: Proposal has a lot more details. 12:24:31 majidvp: Here's an example of a more sophisticated scroll... 12:24:41 majidvp: I like to dream, here's how a gesture might look. 12:25:17 majidvp: [example code] 12:25:44 majidvp: [example of mixing scroll+time] 12:26:03 majidvp: Hidey-bar, for some portion you want to be linked to scroll, when user lifts their ifnger you want to complete animation based on time. 12:26:27