| 00:39 | <MikeSmith> | Krinkle: are y’all use the Beacon API? |
| 00:39 | <MikeSmith> | ..and if so, is it working for you in the way you need? |
| 00:41 | <MikeSmith> | I ask because I’ve made some changes to the sendBeacon() MDN article recently, to try help steer developers in the right direction |
| 00:41 | <MikeSmith> | https://wiki.developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon$history |
| 00:42 | <MikeSmith> | see also https://github.com/mdn/sprints/issues/3722 |
| 00:43 | <MikeSmith> | ...and if you have other suggestions about how MDN could be updated to give better guidance on the Beacon API, lemme know — or chime in on https://github.com/mdn/sprints/issues/3722 |
| 00:44 | <MikeSmith> | annevk: Domenic: by the way, see Phil Walton’s comments about the unload event at https://github.com/mdn/sprints/issues/3722#issuecomment-699526801 |
| 01:36 | <Krinkle> | MikeSmith: if y'all=Wikipedia, then yes, we have used this in production for a while now and happy with its results. |
| 01:37 | <MikeSmith> | Krinkle: cool yeah (and that’s what I meant) |
| 01:37 | <Krinkle> | We don't use it for exit path generally. We do have one infrequent campaign to measure session duration which sometimes beacons from focus/blur/pagehide/visibilitychange, indeed never unload since that event wouldn't fire in most mobile scenarios due to freezing and closing without foregrounding. |
| 01:38 | <MikeSmith> | ah I see |
| 01:38 | <MikeSmith> | yeah unload is nearly useless for mobile |
| 01:39 | <Krinkle> | MikeSmith: I vaguely recall seeing https://volument.com/blog/sendbeacon-is-broken and finding it deceptive since my gut feeling is that sendBeacon works fine wherever you call it, even unload. the issue is just that unload often doesnt fire, there isn't any cirumstances afaik where code runs and calls sendBeacon() but it gets discarded by a browser for reasons specifically relating with how the code calling it got scheduled, right? |
| 01:39 | <MikeSmith> | yup |
| 01:39 | <Krinkle> | ok |
| 01:40 | <Krinkle> | I think the MDN currently is perhaps too strong and might leave a developer thinking there's a logical, spec or implemetnation correlation with unload specifically. |
| 01:40 | <Krinkle> | But.. |
| 01:40 | <Krinkle> | I dont think that's harmful in any way. |
| 01:40 | <MikeSmith> | yeah the person who wrote that blog post is well-intentioned but I think they seem to just be wedded to the idea that unload should be the thing to use (because of the the name) and somewhat unable to see that unload is not what they think it iss |
| 01:41 | <Krinkle> | I'm aware you reduced the severity from a red warning to a little sentence. Just saying, it still certainly sounds like there is correlation. But I also can't think of a more concise way that's helpful. |
| 01:41 | <MikeSmith> | Krinkle: well see https://github.com/mdn/sprints/issues/3722#issuecomment-699526801 |
| 01:41 | <MikeSmith> | > I'd also recommend updating the warning text to recommend never using the unload event—not with with API or any any other APIs |
| 01:41 | <MikeSmith> | > On the Chrome team, we're trying to get the message out that using the unload event is never a good idea. For example, Lighthouse v6.2.0 has added a no-unload-listeners audit, which will warn developers if any JavaScript on their pages (including from third-party libraries) adds an unload event listener, and we may even add a console warning to pages where the unload event is used. |
| 01:41 | <MikeSmith> | .. |
| 01:41 | <MikeSmith> | so that’s pretty strong |
| 01:42 | <Krinkle> | Yeah, I think I commented on that post on some platform somewhere at the time that in our study the failure rate wasn't significantly different from e..g. new Image() or sync XHR from the same event handler. the issue was not with sendBeacon(). |
| 01:42 | <MikeSmith> | OK |
| 01:43 | <MikeSmith> | about unload, given Phil Walton’s comments about what Chrome is doing for Lighthouse (and possible console warning), I think thinking we might want to add some kind of note/warning about unload to the HTML spec itself |
| 01:44 | <Krinkle> | MikeSmith: So yeah, I think strong wording with unload is not accurate but also harmless, and probably useful even. But perhaps on a related note - after seeing this latest edit, I actually thought that maybe we're using it incorrrectly. That is, it sounds now like it is meant to *only* be used to track unload-like scenarios, e.g. that caling it from click() or other scenarios would be unintended use. |
| 01:44 | <MikeSmith> | oh yeah I think so too |
| 01:44 | <MikeSmith> | unintended use, from what you describe |
| 01:45 | <MikeSmith> | though that doesn’t mean it won’t work, or would ever stop working |
| 01:45 | <MikeSmith> | it is more just a side effect |
| 01:46 | <MikeSmith> | well now that I say that, that might not be all true for Safari at least |
| 01:46 | <Krinkle> | hm.. why would you/browsers discourage use of sendBeacon() for e.g. regular UI events and things not relating to the page lifecycle? Is it not generally the recommended path for all async/expect completed beacons? |
| 01:47 | <Krinkle> | like a JS-click for opening a dialog or something. |
| 01:47 | <MikeSmith> | annevk: Domenic: I think maybe we have no precedent for adding a warning for a case like the unload event. But I wonder if we should for this |
| 01:47 | <MikeSmith> | Krinkle: I don’t think it should be discouraged |
| 01:48 | <MikeSmith> | actually I think you might want to even raise an issue in their github tracker to inform them of that use case |
| 01:48 | <MikeSmith> | It might be something they already took into account, I dunno |
| 01:49 | <MikeSmith> | I am not very familiar at all with that API, so it could just be my own ignorance that makes me see that use case as surprising |
| 02:04 | <Krinkle> | MikeSmith: I don't know if it's representative, but to me it's the opposite. We've never specifically targetted tracking unloads. Only every other use case imaginable :P |
| 02:04 | <Krinkle> | but then again, I suppose that might have something to do with working with a non-profit. |
| 02:07 | <MikeSmith> | Krinkle: why would it have anything to do with working for a non-profit? |
| 02:08 | <Krinkle> | I'm implying that heavy tracking of eye-ball time or page abandonment is something a non-profit is much less likely to be interested in. |
| 02:08 | <MikeSmith> | aha |
| 02:08 | <MikeSmith> | yeah, true |
| 02:10 | Krinkle | edited mdn:Beacon_API earlier today to say it is no longer experimental |
| 02:10 | <MikeSmith> | yeah I saw that |
| 02:10 | <MikeSmith> | that is why I pinged you |
| 02:11 | <Krinkle> | k, I figured, but wasn't sure :) |
| 02:11 | <MikeSmith> | yeah, I get notifications when basically every web-platform MDN article other that CSS stuff gets updates |
| 02:11 | <MikeSmith> | ..which is actually a lot less notifications than you imagine |
| 02:11 | <MikeSmith> | *than you might imagine |
| 02:13 | <MikeSmith> | Krinkle: by the way, about WikiMedia and way off-topic, but I came across https://en.wikipedia.org/wiki/User:Guy_Macon/Wikipedia_has_Cancer due to http://calpaterson.com/mozilla.html linking to it |
| 02:13 | <MikeSmith> | ...which should have a far less obnoxious title but the data there still surprised md |
| 02:15 | <MikeSmith> | specifically, that WikiMedia Foundation revenue was $120,067,266 last year, of which $91,414,010 was spent (I guess mostly on staff compensation; it shows currently 415 people on the payroll; 284 staff, 131 contractors |
| 02:16 | <MikeSmith> | anyway, I guess I just had no idea of the scale, as far as revenue and costs and staffing |
| 02:17 | <Krinkle> | (That page is a personal sandbox and not a peer-reviewed article. I think that's clear, but just stating it for the record.) |
| 02:19 | <Krinkle> | those numbers sound about right yeah - https://wikimediafoundation.org/about/annualreport/2019-annual-report/financials/ |
| 02:20 | MikeSmith | looks |
| 02:21 | <Krinkle> | For software engineering, SRE, DC ops, network ops its about ~250 globally I believe. |
| 02:22 | <Krinkle> | essentially running from about 400 apache servers with a 20 server in-house edge cache over 4 pop sites https://wikitech.wikimedia.org/wiki/Clusters |
| 02:22 | <MikeSmith> | that seems about right, as far as staffing |
| 02:23 | <MikeSmith> | well, actually, it seems very low staffing, for running one of the top 10 sites in the world |
| 02:23 | <Krinkle> | yeah, for sure. It's getting quite hard to fill positions where you're effectively required to know everything about everything in every area :P |
| 02:24 | <MikeSmith> | it’s gotta be pretty fun to work on something which gets that scale of people using it |
| 02:24 | <MikeSmith> | haha |
| 02:24 | <Krinkle> | this year we're getting our second dedicated full-time DBA to look after the MySQL/MariaDB core database cluster. |
| 02:24 | <Krinkle> | which is long long overdue |
| 02:24 | <MikeSmith> | wow, only person been doing that? |
| 02:25 | <MikeSmith> | well, DBAs are expensive |
| 02:25 | <Krinkle> | well, 1 full-time. but I suppose 0.1% of a few dozen folks does add up |
| 02:25 | <MikeSmith> | yeah |
| 02:26 | <MikeSmith> | anyway, as far as revenue "Donations and contributions 110,972,163" is inspiring |
| 02:26 | <Krinkle> | these last 3 years have been challenging, converting ourself from a "we're tiny, just getting started, everybody knows each other and knows what to do and gets to do it" to "yeah, no, we're not small anymore, let's formalise things and add (some) bureaucracy". |
| 02:26 | <Krinkle> | I believe our fundraisers like to say that the average donation is $10 |
| 02:27 | <Krinkle> | specifically meant to convey that we're not reliant on any big corporate donors |
| 02:27 | <MikeSmith> | the "we're tiny, just getting started, everybody knows each other" part I can imagine being hard. It’s hard and not as fun once you have to put more bureaucracy around it all |
| 02:28 | <Krinkle> | yeah. |
| 02:28 | <Krinkle> | I've seen the org double 3x in my time here. I joined when we were around 89 staff I think? |
| 02:29 | <Krinkle> | well, I guess that's 2x taking into account the first doubling |
| 02:29 | <MikeSmith> | I would imagine myself hoping it could just stay small |
| 02:29 | <Krinkle> | but I'm actually glad we're letting go of some of the informality. I've seen first-hand the problems it causes when inability to on-boarding means I'm personally on the hook to investigate any/all incidents |
| 02:29 | <MikeSmith> | working for a big-staff organization is just less fun |
| 02:30 | <MikeSmith> | ah yeah, about being on-hook |
| 02:30 | <MikeSmith> | can’t do that forever |
| 02:31 | <Krinkle> | 19 year old me certainly thought he could. |
| 02:33 | <MikeSmith> | anyway for me personally, looking just at the donations side, if W3C could manage to get donations on the order of just 1% of that 110,972,163, I reckon that even that would be at least 10 times what donations we are getting at W3C now |
| 02:33 | <Krinkle> | the start of that 3-year "let's get serious" was the infamous period described in those links with keywords "lila" and "knowledge/search engine". Ideas I can't express much opinion over whether it was smart, but I do know that only a minority stood behind them, and within a few months those were no longer part of the org. |
| 02:33 | <MikeSmith> | ah yeah |
| 02:34 | <Krinkle> | had very long and widespread moral implications beyond their tenure, but at least it was fairly quickly dealt with. |
| 02:34 | <Krinkle> | we lost some good folks during that time |
| 02:35 | <Krinkle> | I know fairly little about how the W3C is internally organised actually, come to think of it. |
| 02:36 | <Krinkle> | Are you full-time there? |
| 02:36 | <MikeSmith> | yeah, we have almost no contractors |
| 02:37 | <MikeSmith> | well that is not true: we have people who work on grant money, a lot for accessibility-related work |
| 02:37 | <Krinkle> | I've mainly been exposed to the working groups part, which to my knowledge is mostly "contributed/sponsored" time, e.g. like how Wikimedia, and Google are members with some of their staff spending some or all of their time on standards work. |
| 02:38 | <MikeSmith> | right |
| 02:39 | <MikeSmith> | the staff mostly do not write specs nor chair groups |
| 02:39 | <MikeSmith> | but instead do on-boarding for chairs, and somewhat, management of chairs |
| 02:40 | <MikeSmith> | many groups and chairs actually need a lot of pushing |
| 02:40 | <MikeSmith> | groups tend to degrade a bit into inaction or infrequent action |
| 02:41 | <MikeSmith> | ..unless someone is pushing them to stay on top of things |
| 02:42 | <MikeSmith> | Philippe Le Hégaret is the one who does the best pushing |
| 02:43 | <MikeSmith> | and he has people who report to him who are the ones that need to be pushing chairs and group |
| 02:43 | <MikeSmith> | so Philippe pushes the pushers |
| 02:45 | <Krinkle> | I see, and #lazyweb - who would generally be the stakholders for which pushers are activated on behalf of? Is that like other memberr orgs? Or does the formal line end there and would they proactively start this on their own based on public interest. |
| 02:45 | <Krinkle> | or based on agreed upon deadlines/commitments? |
| 02:46 | <MikeSmith> | roughly based on schedules in working-group charters |
| 02:47 | <MikeSmith> | but more broadly based on a grander notion that working groups are assets held in trust for the wider web community, churning out new useful web technologies at a regular pace/heartbeat |
| 02:47 | <MikeSmith> | drumbeat, etc |
| 02:49 | <MikeSmith> | so, keep stuff moving through the pipeline and getting shipped in browsers and deployed adopted, so that we can have time/resources to work on the next new thing, and the next |
| 02:50 | <MikeSmith> | but we on the W3C team are in the weird position where we have zero authority to actually keep others working on schedule |
| 02:50 | <Krinkle> | right! |
| 02:50 | <MikeSmith> | yeah |
| 02:51 | <Krinkle> | It's great that all that exists though. I wasn't specifically aware of this, but it makes a lot of sense and I'm glad the W3 is investing in that. |
| 02:51 | <Krinkle> | perhaps we've not yet been naughty enough to be deservant of said push :) |
| 02:52 | <MikeSmith> | heh |
| 02:52 | <MikeSmith> | anyway, there are only about 20 people in total who do the direct engagement like that with groups |
| 02:52 | <Krinkle> | and an order of magnitude more working groups, right? |
| 02:52 | <MikeSmith> | or who are otherwise the “technical” people on staff who do that kind of problem-solving sfuff |
| 02:52 | <Krinkle> | distinct wgs* |
| 02:52 | <MikeSmith> | yeah we have a lot of groups |
| 02:53 | <MikeSmith> | but some groups are run well without as much pushing |
| 02:53 | <MikeSmith> | but anway the only real authority I and others at W3C have is that we can replace working-group chairs who don’t do their jobs, and appoint chairs to begin with |
| 02:54 | <MikeSmith> | well I can also get groups shut down, if they are not producing the way they should be |
| 02:54 | <MikeSmith> | but in practice it’s a lot of hard work to shut a group down — too much inertia |
| 02:55 | <MikeSmith> | anyway, more than you wanted to know, I’m sure |
| 02:55 | <Krinkle> | that's alright. this is good to keep in the back of my mind. |
| 02:56 | <Krinkle> | as I slowly unwind down towards a more healthy 40h work week, I'd very much like to do more on the webapps/webperf/whatwg groups. |
| 02:56 | <MikeSmith> | it would be really great if you could |
| 02:57 | <Krinkle> | for now my time is limited to reading up on emails 10min a week, and attending the bi-weekly video call |
| 02:57 | <MikeSmith> | yup, understood |
| 02:57 | <MikeSmith> | but as far as WGs, webperf is one that could use more active participation from people who don’t work at Google |
| 02:57 | <MikeSmith> | Google is very much carrying most of the weight in webperf |
| 02:58 | <MikeSmith> | you would be a major asset their |
| 02:58 | <MikeSmith> | your insights from your experience |
| 02:58 | <Krinkle> | yeah, and generally upto 1 person from Apple or Mozilla |
| 02:59 | <Krinkle> | would like to see more involvement from there as well. |
| 02:59 | <Krinkle> | I often feel aligned with some of the ideas from Apple in that group, but not as much proactive work toward concrete ways to realize those ideas. I'd like to try some of that. |
| 03:02 | <MikeSmith> | I hear you, about alignment |
| 03:02 | <MikeSmith> | there are issues with some of webperf API designs |
| 03:03 | <MikeSmith> | but IMHO those are artifacts of not enough others paying attention and taking time to be involved |
| 03:04 | <MikeSmith> | well, also webperf editors need to take more responsibility themselves for taking initiative to do better implementor engagement, the way that WHATWG editors do |
| 03:05 | <MikeSmith> | browser implementor are chronically busy and lazy and have limited attention specs :p |
| 03:06 | <MikeSmith> | *attention spans |
| 03:11 | <Krinkle> | ack yeah, we need that. |
| 03:11 | <Krinkle> | I admitedly have no experience doing that thus far, though. |
| 07:19 | <annevk> | MikeSmith: yeah maybe, although it has been improvement, the lifecycle of a document is still somewhat poorly written out so I suspect there's a bunch of browser inconsistencies too |
| 07:19 | <annevk> | improved* |
| 07:20 | <annevk> | or maybe I meant to write seen |
| 07:23 | <annevk> | GitHub Actions is so much faster than Travis CI, it's hard to believe |
| 10:24 | <annevk> | littledan: so what's really the difference conceptually between accomplishing error or module through keying or the PR mechanism? The module map isn't directly observable. Implementations can optimize this either way. I guess there's something I'm missing and we probably discussed this a couple months back as well? |
| 10:29 | <zcorpan> | yoav: does chromium run "update the image data" during a forced reflow? |
| 10:32 | <yoav> | zcorpan: not sure off the top of my head... |
| 10:32 | <yoav> | related to https://github.com/whatwg/html/pull/5894 ? |
| 10:33 | <zcorpan> | yoav: yeah, I was playing around in live dom viewer. Seems this isn't interoperable: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/8516 |
| 10:35 | <zcorpan> | webkit even keeps the old dimensions applied |
| 10:36 | <yoav> | hmm |
| 10:36 | <yoav> | what's the specified behavior? |
| 10:39 | <zcorpan> | yoav: https://html.spec.whatwg.org/multipage/images.html#relevant-mutations runs "update the image data", which queues a microtask in step 7 before selecting an image source in step 9 |
| 10:40 | <zcorpan> | yoav: so to the currently running script it's still the old image |
| 10:40 | <yoav> | ok, yeah |
| 10:40 | <yoav> | I believe that should be running for relevant mutations but not sure about other forced reflows |
| 10:41 | <yoav> | https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/html/html_source_element.cc;l=115?q=html_source_element&ss=chromium%2Fchromium%2Fsrc:third_party%2Fblink%2Frenderer%2F&start=1 |
| 10:42 | <yoav> | (for HTMLSourceElement specifically) |
| 11:03 | <annevk> | andreubotella: I'll likely fix the JSON mistake in default-RD in https://github.com/tabatkins/bikeshed/pull/1726 |
| 11:11 | <andreubotella> | annevk: I did fix it in my PR, but if you're merging that first, sure |
| 11:12 | <annevk> | andreubotella: I think to merge your PR we need to merge the whatwg.org PR and you wanted to wait for the HTML PR before doing that, right? If so, I would expect this to go first |
| 11:12 | <annevk> | This does require a bunch of follow-up work, but none of it blocking |
| 11:13 | <andreubotella> | I'm about to push the changes MikeSmith wanted me to do |
| 11:13 | <andreubotella> | they'll need some review, though, so yeah, go ahead |
| 11:15 | <annevk> | andreubotella: I can rebase if it comes to that, but I kinda hope that git is smart enough |
| 11:26 | <littledan> | annevk: I think these differences are observable. For example, even with the `type`-only restriction, there are observably different numbers of fetches if you import with different types (I think we did discuss this some months ago, and I'm fine with concluding that this is an unimportant edge case). |
| 11:27 | <littledan> | The thing I'm more concerned about is non-type assertions. I'd prefer for these to be ignored and not treated as part of the cache key. If we can agree on that, then I'm fine with this greater number of fetches for varying `type`, though I still don't understand the motivation. |
| 11:34 | <littledan> | it's also observable what we choose for non-`type` assertions. For example, if we permitted them and ignored them but treated them as part of the key, or had an error on all of them. The choice here has implications for what other kinds of assertions we could compatibly add in the future. |
| 12:36 | <zcorpan> | yoav: what I really wanted to do was something more fancy: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=8517 |
| 13:16 | <annevk> | littledan: so I'm not sure that's true in the context of the memory cache (which is undefined, but still) |
| 13:17 | <littledan> | annevk: Does this depend on the cache headers of the response? |
| 13:17 | <annevk> | littledan: I think it would help to spell edge cases out to make an informed decision |
| 13:17 | <annevk> | littledan: well, there's that too, but the memory cache does not depend on that |
| 13:17 | <littledan> | oh, I see. where can I learn more about the memory cache? |
| 13:18 | <annevk> | littledan: I guess in WebKit/Chromium's codebase? https://github.com/whatwg/fetch/issues/590 has some context |
| 13:22 | <annevk> | andreubotella: seems git deals with it fine |
| 13:25 | <annevk> | TabAtkins: can you separate text macros by anything other than a newline? |
| 13:25 | <annevk> | TabAtkins: e.g. Text Macro: X XVAL, Y YVAL |
| 13:26 | <andreubotella> | annevk: rebased |
| 13:26 | <annevk> | TabAtkins: oh, I also get "Unknown include/exclude-if condition 'boilerplate:ipr'" |
| 13:39 | <annevk> | Maybe csswg.org is not up-to-date yet |
| 13:41 | <annevk> | Hmm no that doesn't make sense |
| 13:43 | <annevk> | TabAtkins: could that be because there's no continue statements after the yield? |
| 13:51 | <andreubotella> | annevk, TabAtkins: The conditional includes seem to be handled only after the macros are replaced, so the build is failing without the LATESTRD macro |
| 13:51 | <andreubotella> | this might not be something worth fixing, since if the include ends up in the spec, there's no downside in using [LATESTRD?] |
| 13:51 | <andreubotella> | *something worth fixing from the Bikeshed side, not from the WHATWG side |
| 13:53 | <annevk> | andreubotella: where did you see that failure? |
| 13:53 | <andreubotella> | building locally on my rebased branch |
| 13:53 | <annevk> | andreubotella: I see, we could make it LATESTRD? I guess |
| 13:57 | <annevk> | andreubotella: I'll do that and it seems to me that https://github.com/tabatkins/bikeshed/pull/1774 fixes the other issue |
| 14:00 | <annevk> | andreubotella: https://github.com/tabatkins/bikeshed/pull/1775 if that seems reasonable to you as well I'll land these so we can get on with it :-) |
| 14:00 | <annevk> | and if it continues to fail I'll back it all out |
| 14:00 | <andreubotella> | that's fine by me |
| 14:03 | <annevk> | It takes a long time to build DOM locally |
| 14:08 | <annevk> | andreubotella: bikeshed fixes are landed |
| 14:09 | <annevk> | TabAtkins: please review when you're awake and let me know if I should never do that again 😊 |
| 14:14 | <zcorpan_> | I don't follow how what the spec does for <script src=X></script> where X is: document.write("<script src=Y></script><img src=Z>"); |
| 14:14 | <zcorpan_> | first there's https://html.spec.whatwg.org/multipage/parsing.html#scriptEndTag |
| 14:15 | <zcorpan_> | "Prepare" will mark the script as the pending parser-blocking script, for the first script |
| 14:15 | <zcorpan_> | "script nesting level" is zero, so the Otherwise steps are run |
| 14:15 | <zcorpan_> | so far so good. This is where I want to kick off the (first) speculative parser |
| 14:17 | <zcorpan_> | but then the script is loaded and executed (step 10), and the document.write will invoke the tree builder reentrantly, reaching this part again but with "script nesting level" being 1 |
| 14:18 | <zcorpan_> | where the spec says "Set the parser pause flag to true, and abort the processing of any nested invocations of the tokenizer, yielding control back to the caller. (Tokenization will resume when the caller returns to the "outer" tree construction stage.)" |
| 14:19 | <zcorpan_> | and that's what I don't get. how is the Y script loaded and executed? |
| 14:19 | <zcorpan_> | Where should I kick off a second speculative parser to find the img in the document.write string |
| 14:31 | <annevk> | Creating a bunch of PRs always leads to finding lots of novel xref issues, sigh |
| 16:30 | <TabAtkins> | annevk: You do multiple text macros by supplying the key multiple times. Text macros can expand into *any* text, so I couldn't rely on any delimiter at all. |
| 16:40 | <annevk> | TabAtkins: yeah, fair |
| 16:40 | <TabAtkins> | (Newline happens to work because of the shorthanding where if you newline+indent, it's the same as repeating the previous key.) |
| 17:16 | <TabAtkins> | annevk: I've also added a note to the docs about making sure you make the macro optional if you're conditioning on its existence; the ordering of macros vs conditionals isn't something I can change. Thanks for noticing it! |
| 18:01 | <devsnek> | would the web still be interested in that "blöcks" proposal |
| 18:02 | <devsnek> | i was thinking of looking at it again, my motivation more being node's worker api |
| 18:52 | <annevk> | TabAtkins: thanks, expected as much; credit to andreubotella though |
| 19:31 | <Domenic> | devsnek: a while back folks from Chrome pivoted away from workers and to scheduling (https://github.com/WICG/main-thread-scheduling) because they found the cross-thread communication overhead was prohibitive for realistic use cases. I will see if I can find the analysis they did. So, it's no longer considered high priority to make workers more ergonomic, from Chrome's perspective. |
| 19:32 | <Domenic> | That said, I think for people who *are* using workers on the web, blöcks would be nice. Maybe nice enough for the web to spec and ship a worker blöck, although as usual speccing/shipping sugar features that can also be accomplished in libraries seems hard for any vendor to prioritize. |
| 19:46 | <devsnek> | Domenic: thanks for the info |