| 06:16 | <MikeSmith> | is Service Worker importScripts(urls) still needed or can the same thing be accomplished with ES6 modules/imports |
| 06:17 | <MikeSmith> | JakeA: ⬆️ |
| 07:39 | <JakeA> | MikeSmith: I'm hoping we can replace it with imports. There's some spec work to be done here so we can cache the resulting module tree |
| 07:40 | <MikeSmith> | super |
| 07:41 | <JakeA> | Moz folks: https://twitter.com/jaffathecake/status/879626556544618496 — I've asked for evidence here a few times, is there something I'm missing? |
| 07:41 | <JakeA> | Given some of the blog posts etc I've seem from Mozilla I'm worried it's a new strategy |
| 07:49 | <annevk> | JakeA: I kinda doubt it's related to that, but I've also got no special insights |
| 07:52 | <annevk> | JakeA: and as far as the new marketing strategy thing, I mostly understood that to be about pushing back a bit since Google advertising Chrome all over Google properties is obviously not helping Firefox |
| 07:53 | <annevk> | JakeA: I hope it takes a constructive form and that that blogpost was just a fluke (it was deleted from the official @firefox account after all), but time will tell |
| 07:54 | <JakeA> | annevk: the negative campaigning makes me sad, but I get it. I'm more worried about the hate-fiction "here's what Google people are saying…" stuff |
| 07:55 | <JakeA> | I guess I should just continue to ask for evidence and hope others do the same |
| 07:57 | <annevk> | JakeA: it seems a little disingenuous to go from "not that I don't believe you" to "hate-fiction" |
| 07:59 | <JakeA> | annevk: time was a factor there. I ask multiple times over multiple days. I assumed it either truthful or a misunderstanding at first, but now (plus other things) I'm worried it's deliberate |
| 10:00 | <annevk> | smaug: do you support https://github.com/whatwg/dom/pull/467? |
| 10:00 | <annevk> | smaug: giving EventTarget a constructor that is |
| 10:01 | <smaug> | annevk: sure, but how do I see the actual proposal |
| 10:01 | <smaug> | I guess some pr, but don't know which one |
| 10:01 | <annevk> | smaug: that's a link to the PR |
| 10:02 | <annevk> | smaug: each PR in whatwg/dom has Preview and Diff links in the first message |
| 10:02 | <smaug> | is there some way to see that in more readable form |
| 10:02 | <smaug> | ahaa |
| 10:02 | <smaug> | now I need to find the Preview link :) |
| 10:02 | <annevk> | smaug: bottom of the first message |
| 10:03 | <smaug> | so there is no parent links here? |
| 10:04 | <smaug> | do we think EventTarget will be used without parent links? |
| 10:04 | <annevk> | smaug: folks could use it for XMLHttpRequest or WebSocket-like classes |
| 10:04 | <smaug> | is that something people need? |
| 10:05 | <annevk> | smaug: given that Node.js ended up inventing its own eventing system, I'd think so |
| 10:05 | <smaug> | and they don't have event target chain? |
| 10:06 | <annevk> | smaug: I don't think so, given https://nodejs.org/api/events.html |
| 10:06 | <annevk> | smaug: note that we could add a parent chain feature later |
| 10:07 | <annevk> | smaug: this is just the most minimal thing we can do |
| 10:07 | <smaug> | just wondering if we are adding something no one will use |
| 10:07 | <smaug> | (we have too many such features in the platform) |
| 10:11 | <annevk> | That event libraries exist make me somewhat hopeful, but it's always a risk of course |
| 10:14 | <smaug> | annevk: there is also the thing that if script libraries implement their own event target object, they can keep all processing in JS and possibly performance is better |
| 10:15 | <annevk> | smaug: that's something we should really try to solve over time, performance cliffs when you touch browser-implemented libraries is a problem |
| 10:15 | <annevk> | smaug: but it seems similar to suggesting folks should use JavaScript to animate because CSS animation isn't optimized, or some such |
| 10:16 | <annevk> | smaug: not great long term advice |
| 10:16 | <smaug> | not really similar |
| 10:16 | <smaug> | native side and JS side really both have their advantages |
| 10:17 | <smaug> | say, doing anything which touches lots of nodes in JS is slow, since it guarantees the wrappers must be created |
| 10:17 | <smaug> | so native helper methods are good for that kind of case |
| 10:18 | <smaug> | (my current guess is that servo will need to change their DOM implementation to be more like in other browsers to not create wrappers since beginning) |
| 10:37 | <smaug> | hmm, in general, should we think of how to make the platform faster |
| 10:38 | <smaug> | like create such APIs that if script libraries were using those, it would more likely that web pages would be less janky or load faster |
| 10:39 | <smaug> | so far it has been more like ad-hoc approach |
| 10:39 | <MikeSmith> | isn’t that what the webperf group is supposed to be focused on |
| 10:40 | <annevk> | smaug: could you comment in https://github.com/whatwg/dom/issues/414 about event creation? |
| 10:41 | <smaug> | MikeSmith: they seem to focus on measurements |
| 10:41 | <MikeSmith> | yeah I guess so |
| 12:24 | <annevk> | HTML no longer links to legacy bugs? |
| 12:37 | <JakeA> | smaug: fwiw I've wanted to have an extendable EventTarget in my own projects, and have used libraries since I couldn't use the browser's. |
| 12:37 | <JakeA> | I haven't needed bubbling |
| 12:37 | <JakeA> | I might not need it as much in a web components world, since I get it for free |
| 12:38 | <smaug> | JakeA: have you had parent chain with these event target like objects? |
| 12:39 | <JakeA> | smaug: if you mean capturing/bubbling, no, I haven't needed it |
| 12:39 | <smaug> | aha, I thought you just didn't need bubble phase |
| 12:40 | <smaug> | but ok, no propagation |
| 12:40 | <JakeA> | yeah, sorry. I mean I haven't needed the chain |
| 13:47 | <wanderview> | JakeA: to your question to "moz folks" above... i think we've had these concerns for a while... its not google saying "ignore best practices", but instead signal boosting anything related to PWA with other web best practices relegated to a footnote or ignored completely... classic example I can think of is flipkart (which obviously I was concerned about long before we had a billboard) |
| 13:48 | <wanderview> | flipkart worked out in the end... but it easily could have gone sideways |
| 13:49 | <JakeA> | wanderview: in terms of it being Chrome only? |
| 13:50 | <JakeA> | (my memory is foggy here, was it Chrome only?) |
| 13:51 | <wanderview> | JakeA: I took an animated gif of what it did at the time here: https://blog.wanderview.com/blog/2016/06/10/flipkart-google-and-the-web/ |
| 13:51 | <wanderview> | I don't really want to re-litigate that |
| 13:51 | <wanderview> | I only mention it in response to the question "is this a new sinister messaging plot from mozilla" |
| 13:52 | <wanderview> | if anything, mozilla is a cacophony of voices and coherent messaging is one of the things we don't know how to do at all |
| 13:53 | <JakeA> | wanderview: that's fair. I agree that Flipkart at the time was a poor example of the P in PWA, but I hope we never suggested that their initial shrugging of Firefox was a good (or ok) thing |
| 13:54 | <JakeA> | I guess that might have seemed implicit by singing Flipkart's praises. |
| 13:54 | <wanderview> | JakeA: google boosted it as a good example... never said that practice was bad in a public place... what is the implication to random people reading about it? |
| 13:54 | <wanderview> | yea |
| 13:54 | <JakeA> | Back then, PWA examples were thin on the ground, but I take your point |
| 13:55 | <wanderview> | JakeA: anyway, I don't see that happening as much lately... but I'm not keyed into other web practices that might be getting less coverage like accessibility |
| 13:55 | <wanderview> | I do recall accessibility being on topic at PWA Summit last year, though |
| 13:55 | <JakeA> | I think I publicly said it wasn't progressive (and complained about the lack of server rendering) |
| 13:55 | <wanderview> | JakeA: but I think its more from this kind of thing that people are concerned |
| 13:56 | <wanderview> | JakeA: sure, and that was appreciated... but a tweet is poorly balanced against glossy copy on a google.com domain |
| 13:58 | <JakeA> | That's fair |
| 14:01 | <wanderview> | JakeA: obviously google can't always be saying "PWA's are awesome, but let me talk for an hour about all the other web stuff you should also be doing"... so I see why things have been done the way they have and I don't think it was sinister in any way... but I also just understand why some people are concerned |
| 14:01 | wanderview | sees both sides and has no solutions. |
| 14:01 | wanderview | is useless. |
| 14:02 | <wanderview> | I think things like you the slide you linked above in your tweet are good |
| 14:02 | <wanderview> | including accessibility topics in summits is good |
| 14:02 | <wanderview> | and on balance "PWA" has been good |
| 14:03 | <JakeA> | wanderview: I'm also concerned about the lack of P in many PWAs. But yeah, we need to increase the volume on PWA != SPA |
| 14:04 | <wanderview> | JakeA: I agreed with a lot of Jeremy's post: https://adactio.com/journal/12461 |
| 14:08 | <JakeA> | Same |
| 14:21 | <nox> | JakeA: Given you are a Googler, what is your opinion on the Houdini stuff? |
| 14:24 | <nox> | If you have any, that is. |
| 14:24 | <JakeA> | nox: It's sometimes difficult to figure out what's part of it and what isn't. The typed OM for CSS is much needed, especially now we have things like DOMMatrix. I'm not hugely excited about a paint worklet, but I might be lacking imagination. I'm very excited about an animation worklet, for running animations on the compositor thread and linking them to things like scrolling. I'm fascinated about what custom layout will allow. |
| 14:24 | <nox> | JakeA: What I had in mind was custom paint etc, |
| 14:24 | <nox> | things that pcwalton doesn't like, based on knowledge I don't possess. |
| 14:24 | <JakeA> | But I haven't read any of the specs in detail, so I'm only commenting on vague details |
| 14:25 | <nox> | Ok. |
| 14:26 | <annevk> | Didn't pcwalton mention compositor could maybe be merged with some other layer, maybe paint? |
| 14:26 | <JakeA> | nox: I didn't know that pcwalton wasn't keen on it. I imagine him having more to say about the compositor & layout stuff than paint |
| 14:26 | <nox> | Oh yes. |
| 14:27 | <nox> | JakeA: My knowledge is so limited I still have troubles distinguishing all these parts from each other. :D |
| 14:27 | <JakeA> | Same! |
| 14:27 | <nox> | "The solutions that the Chrome team keeps proposing—Custom Layout, Custom Paint, CSS Compositing, etc. are all targeted toward rendering (and they're essentially short-term band-aids at that). If rendering really weren't a problem, then we wouldn't be spending all this time on Google's Houdini proposals! If layout were fast, we wouldn't see people |
| 14:27 | <nox> | implementing layouts in JS, and therefore we wouldn't need Custom Layout. If painting were fast, then we could use SVG and CSS and not feel like Custom Paint is necessary. If the main thread weren't so bogged down all the time, then people wouldn't see the need to move a random subset of the Web platform to the compositor thread." |
| 14:27 | <nox> | is the piece I had in mind. |
| 14:28 | <nox> | https://news.ycombinator.com/item?id=14427494 |
| 14:29 | <JakeA> | I disagree in regards to layout. In an ideal world we should have been able to polyfill grid before browser support landed. |
| 14:30 | <JakeA> | For me, it's about being able to add features in a fast way, rather than taking an existing feature and making it faster. |
| 14:31 | <nox> | JakeA: Isn't his point that if things were fast enough, they could be polyfilled without custom layout? |
| 14:31 | <JakeA> | nox: Wouldn't that involve implementing layouts in JS? Whereas he suggested it was performance (not features) that caused people to do that |
| 14:32 | <nox> | AFAIU his comment, he is saying people are pushing for custom layout because implementing layout in JS is too slow, because of architectural issues in general in the major browsers. |
| 14:32 | <nox> | Oh I misread that indeed. |
| 14:33 | <nox> | JakeA: Later he agrees with you I think. "That's fair. I don't have an issue with Houdini if it's actually used to create custom layouts that you can't reasonably do in CSS." |
| 14:34 | <gsnedders> | Houdini is mostly JS APIs, though. So surely it would involve implementing layouts in JS whatever you do? |
| 14:34 | <JakeA> | Ahh, fair enough. I agree with that bit. I'm interested in a world were layout performance isn't an issue, but I'd need to see it to believe it :D |
| 14:34 | <JakeA> | gsnedders: I think the plan is to spin up light weight worklets in multiple threads |
| 14:35 | <nox> | JakeA: I take pcwalton's comment as "SERVO GOT 99 ISSUES, BUT FAST LAYOUT AIN'T NONE" |
| 14:35 | <nox> | :) |
| 14:35 | <JakeA> | haha |
| 14:35 | <JakeA> | I guess I should try and get a build working on a phone and throw some width/height animations at it |
| 14:36 | <nox> | 2,169 (known) issues, to be correct. |
| 14:36 | <annevk> | I doubt it'll be a non-issue (especially now there's the 120 Hz push from Apple and the eventual 240 Hz push for VR), but I do believe Servo shows we can do much better |
| 14:36 | <wanderview> | in fairness, servo's parallel layout is incomplete and more of a proof-of-concept |
| 14:36 | <nox> | wanderview: It's not *that* incomplete. |
| 14:36 | <JakeA> | I'm fighting for moving clip-path to the compositor, as "reveal" animations seem to be our sticking point right now |
| 14:36 | <annevk> | nox: pcwalton said it basically needed to be redone |
| 14:36 | <nox> | annevk: WR 42 could exist that Patrick would say it needs to be redone, IMHO. :P |
| 14:37 | <annevk> | nox: current architecture doesn't scale well or some such |
| 14:37 | <annevk> | nox: not sure what WR 42 is |
| 14:37 | <nox> | Oh ok. |
| 14:37 | <nox> | annevk: WebRender 42. |
| 14:37 | <nox> | annevk: I'm just saying Patrick and Glenn seems to be rewriting it every 6 months. :) |
| 14:37 | <annevk> | nox: WebRender isn't parallel layout though |
| 14:37 | <annevk> | nox: WR is post-layout |
| 14:37 | <nox> | annevk: Cf. what I said earlier about not distinguishing them parts. |
| 14:38 | <nox> | annevk: You are right. |
| 14:38 | <annevk> | nox: parallel layout is box creation and such |
| 14:38 | <nox> | Layout is the crate that scares me just as much as WR so I can't distinguish them in my mind. ( ._.) |
| 14:38 | <annevk> | hah |
| 14:43 | <gsnedders> | JakeA: tbf, AIUI some of the objections to it are the fact that some of the perf bottlenecks used to justify Houdini are essentially "this isn't in the compositor" when Servo shows you can do them in the compositor |
| 14:44 | <JakeA> | annevk: The HTML spec is complaining at me using <code> (because there's no dfn), but I'm using it for things like byte-sequences. What's the workaround? |
| 14:44 | <annevk> | JakeA: <code data-x="">...</code> |
| 14:44 | <JakeA> | \o/ cheers |
| 14:45 | <Domenic> | When I tried Servo it was super-slow, so I was not impressed by the claims of servo showing we can do better... Planning to re-judge when someone shouts from the Twitters that there has been progress, but I think at least the narrative that if you just do everything right from scratch it will be fast is falsified. You still need a lot of optimization effort to get something reasonable for the web. |
| 14:46 | <annevk> | From Twitter, update on Streams: https://blog.whatwg.org/progressing-streams |
| 14:46 | <Domenic> | annevk: "HTML no longer links to legacy bugs?" I haven't noticed that, but it's plausible we broke it somewhere :-/ |
| 14:46 | <annevk> | Domenic: afaict the top just has "Open Issues" |
| 14:46 | <Domenic> | annevk: oh, the top, not the margins |
| 14:47 | <Domenic> | Yeah I removed that to make room for the dev edition because an odd number of things looks really bad on mobile |
| 14:47 | <gsnedders> | Domenic: super-slow perceptively? |
| 14:47 | <Domenic> | gsnedders: yeah, just trying to browse some websites and scroll and click things |
| 14:48 | <gsnedders> | Domenic: AFAIK a lot of that is simply the fact that things that make a big perceptive difference are quite bad, though the traditionally slow stuff like layout is super-fast |
| 14:48 | <Domenic> | Sounds plausible I guess. |
| 14:49 | <nox> | Cf. the demo by a googler with the animated shapes. |
| 14:49 | <nox> | Domenic: I don't do any graphics or layout or whatever, but I do some DOM in Servo, |
| 14:50 | <nox> | Domenic: animations and whatnot can hit 60 fps with no issues, and aside from that then you have HTMLCollection that is extremely naive, |
| 14:50 | <nox> | and for example in the past if you did for elem in collection, |
| 14:50 | <nox> | it would just internally call collection.item(i) for all i from 0 to the length of the collection, |
| 14:51 | <nox> | and the traversal to retrieve the ith element would always start from the root of the document. |
| 14:51 | <JakeA> | nox: that might have been me https://www.youtube.com/watch?v=u0hYIRQRiws - but it didn't involve layout |
| 14:52 | <nox> | So yeah, some things are extremely slow. |
| 14:52 | <nox> | JakeA: Ugh, yes and yes. |
| 14:52 | <nox> | I'll just assume that layout is never what I have in mind. ;) |
| 14:53 | <nox> | JakeA: Oh right, animations obviously are post-layout, is that right? |
| 14:53 | <JakeA> | nox: it was only changing transform, background & border-radius, none change layout |
| 14:54 | <nox> | JakeA: Right. Hence why you mentioned animating width and height earlier, right? |
| 14:55 | <JakeA> | Yeah, those would change layout inside and probably outside the element |
| 14:56 | <JakeA> | http://output.jsbin.com/surane/quiet runs very well in Safari these days (in the tech preview at least) |
| 16:41 | <annevk> | wanderview: there's tests for AbortController and AbortSignal |
| 16:41 | <annevk> | wanderview: not sure about fetch() + AbortSignal, JakeA might know |
| 16:42 | <annevk> | wanderview: I guess if we had tests for fetch() + AbortSignal that would be enough to proceed with the impl, perhaps we should focus on that first rather than figuring out how to refactor Fetch |
| 16:48 | <JakeA> | annevk: I can pick that up |
| 16:50 | <annevk> | JakeA: cool, I guess if we can put all the edge cases in tests, it'll make it easier to figure out the spec (or at least we know what it should say) |
| 16:57 | <JakeA> | annevk: the tests shouldn't include signals in a service worker right? That's v2? |
| 17:14 | <annevk> | JakeA: yeah, though passing a signal to fetch() in a service worker should work |
| 17:17 | <JakeA> | annevk: yeah, I'll test in worker contexts too. What's the purpose of t.step_func? Does the test fail if one of the step_funcs isn't called? |
| 17:18 | <annevk> | JakeA: it makes sure that exceptions in callbacks get routed to the test as well |
| 17:18 | <annevk> | JakeA: basically makes callbacks part of the test |
| 17:19 | <JakeA> | ahhhh yeah of course |
| 17:19 | <JakeA> | (I've only written promise tests so far) |
| 17:19 | <wanderview> | annevk: keeping everything in promises kind of does the same, though |
| 17:19 | <wanderview> | and you don't have to pass t around |
| 17:20 | <annevk> | wanderview: yeah, it makes less sense to use for promise APIs I suppose, though you'll need it here for the callback maybe? |
| 17:20 | <annevk> | wanderview: that is, the abort event |
| 17:20 | <wanderview> | ok |
| 17:20 | <wanderview> | I have mostly avoid t.step_func() because I didn't understand it |
| 17:21 | <JakeA> | It makes sense in https://github.com/w3c/web-platform-tests/pull/5960/files as it needs to ensure the event fires synchronously |
| 17:21 | wanderview | just presses keys till the thing works... |
| 17:21 | <JakeA> | Same :D |
| 17:22 | <annevk> | Basically if you don't use it and the browser fails something you get a global failure and otherwise you just get a test failure |
| 17:22 | <annevk> | But it's a little tricky indeed, especially with all the t.step_func_done() variants and such |
| 22:25 | <TabAtkins> | nox: pcwalton's opining on Houdini is missing the entire point; you *absolutely cannot* implement layout in JS today in a way that faithfully interacts with the built-in layout system properly (for example, providing proper min-content and max-content contributions, which Flex and Grid layout use extensively). |
| 22:25 | <TabAtkins> | The point of Houdini isn't to magically make anything faster, but to provide the correct hooks into the existing systems. |
| 22:26 | <nox> | TabAtkins: I think that's the part of Houdini he conceded was useful, no? |
| 22:26 | <TabAtkins> | (It will in many cases make things faster, as we can provide you the right information and only ask you to do work when it's needed, but that's a benefit on top.) |
| 22:26 | <nox> | Or did you mention layout just as an example? |
| 22:26 | <TabAtkins> | Just as an example. |
| 22:28 | <TabAtkins> | Same applies to, for example, Paint - Houdini gives you the right lifecycle hooks (draw only when we need a new image) and the right information (here's the size the image will be rendered at) to let you do correct, efficient painting. Without Houdini, you can draw to a canvas and render to a data url, but your image won't be at the proper resolution (matching up canvas pixels to screen pixels) unless you manually coordinate |
| 22:28 | <TabAtkins> | things, and you'll probably draw too early, and/or too often. |
| 23:22 | <jolvera> | would be useful to add some kind of syntax highlighting for code snippets? |
| 23:22 | <jolvera> | e.g. https://dsh.re/5918b |