| 00:24 | <devsnek> | where does the fetch spec sit in relation to reading and writing bytes over a tcp socket |
| 00:45 | <Domenic> | two levels above that |
| 01:00 | <devsnek> | tfw you click on "handle fetch" and now you have to think about service workers |
| 01:07 | <TimothyGu> | devsnek: is this related in anyway to zero |
| 01:07 | <devsnek> | TimothyGu: yes |
| 01:07 | <TimothyGu> | ah |
| 01:07 | <devsnek> | i have a socket binding |
| 01:07 | <devsnek> | just need to plug fetch into it |
| 01:07 | <devsnek> | but this spec is spaghetti |
| 01:08 | <devsnek> | i've gone through like 5 different "concept fetch" algorithms and i still haven't found where an actual network request happens |
| 01:08 | <TimothyGu> | ah yeah |
| 01:09 | <devsnek> | hmmm here we go "concept-http-network-fetch" |
| 01:09 | <devsnek> | so all fetch requests are pooled with keepalive |
| 01:12 | <TimothyGu> | devsnek: btw I'd heavily recommend using node-fetch as a guide |
| 01:12 | <devsnek> | this API is just so enormous 😓 |
| 01:12 | <devsnek> | I looked at it |
| 01:13 | <devsnek> | would be a good guide if I had an existing http interface |
| 01:13 | <devsnek> | but I'm going from scratch |
| 01:13 | <TimothyGu> | still |
| 01:14 | <TimothyGu> | you can kind of see what steps are required |
| 01:14 | <TimothyGu> | up to you ofc |
| 01:14 | <devsnek> | yeah I've looked through it a few times |
| 01:14 | <devsnek> | believe me I'm trying to take every shortcut I can |
| 07:00 | <zewt> | bluh, browsers sure don't like nesting hover transitions inside scroll-behavior: smooth |
| 07:09 | <zewt> | man, smooth scrolling is nasty |
| 07:09 | <zewt> | doesn't even send mouseover events until it stops completely |
| 07:09 | <zewt> | smells like ancient optimizations that just make a mess of things now |
| 07:11 | <zewt> | and chrome doesn't send them at all until the mouse moves |
| 19:34 | <TimothyGu> | Are commit snapshots available for the HTML spec? |
| 20:43 | <Domenic> | TimothyGu: yeah, /commit-snapshots/ |
| 20:43 | <Domenic> | MikeSmith: highlighter is not working on Ci despite my best efforts :-/. https://travis-ci.org/whatwg/html/jobs/407320112#L2920 |
| 20:44 | <TimothyGu> | Domenic: heh ok |
| 20:44 | <TimothyGu> | Also, is there a way to get a reference to a document that's not in the origin of the current window? |
| 20:44 | <Domenic> | You can get documents that are cross-origin but not ones that are cross-origin-domain |
| 20:44 | <Domenic> | Basically, use document.domain |
| 20:47 | <Domenic> | Hmm IDL highlighting is working though |
| 20:50 | <Domenic> | MikeSmith: but non-Web IDL blocks have gotten their contents stripped to zero |
| 20:50 | <Domenic> | s/zero/empty string |
| 20:51 | <TimothyGu> | Domenic: I'm trying to use document.domain to get around the port restriction |
| 20:51 | <TimothyGu> | As the warning says "as the ports are ignored when comparing origins after the document.domain attribute has been used" |
| 20:52 | <Domenic> | yeah that should work |
| 20:52 | <TimothyGu> | But I haven't been able to do that |
| 20:52 | <Domenic> | Both pages need to set document.domain |
| 20:53 | <TimothyGu> | Yeah I'm doing that |
| 20:53 | <TimothyGu> | I'm also using localhost for testing |
| 20:53 | <TimothyGu> | Maybe that's part of the reason? |
| 20:54 | <TimothyGu> | specifically, I don't see how the effect of the port is cancelled out in domain's setter: https://html.spec.whatwg.org/#dom-document-domain |
| 20:58 | <Domenic> | It sets the domain component. And all same-origin-domain checks (including property access) only compare domain |
| 20:58 | <Domenic> | https://html.spec.whatwg.org/#same-origin-domain |
| 20:58 | <TimothyGu> | jk I got it |
| 20:58 | <Domenic> | \o/ |
| 21:33 | <Domenic> | If anyone understands how Python include paths works and wants to help debug... https://github.com/whatwg/html-build/issues/169 |
| 21:41 | <TimothyGu> | annevk / Domenic: thoughts on what to do for https://github.com/whatwg/html/issues/3836? Haven't tested Edge yet, but aligning with three browsers sounds fine to me |
| 21:42 | <Domenic> | TimothyGu: agreed! |
| 21:43 | <jgraham> | Domenic: No idea what you are doing there, but if you're hacking PYTHONPATH something has gone wrong |
| 21:43 | <jgraham> | Pretty sure you want to be running pip install on pygments at some point, which I don't see in your revert |
| 21:43 | <Domenic> | jgraham: yeah that was my impression |
| 21:43 | <TabAtkins> | No he doesn't. I've already diagnosed the error. |
| 21:43 | <jgraham> | But like I say I don't know what the overall setup is here |
| 21:43 | <TabAtkins> | (It's a bug on Pygments' part, but I can fix it locally.) |
| 21:44 | <Domenic> | jgraham: pygments is bundled somewhere |
| 21:44 | <TabAtkins> | (The bug you're running into: https://bitbucket.org/birkenfeld/pygments-main/issues/1448/pygments-relies-on-global-imports-of-its) |
| 21:45 | <Domenic> | Maybe it expects to be pip installed but in our setup it's bundled so this causes issues? |
| 21:45 | <TabAtkins> | Domenic: You... you can see my messages, right? |
| 21:45 | <Domenic> | Sorta, on a train so laggy :) |
| 21:45 | <TabAtkins> | Ah, kk. ^_^ |
| 21:45 | <Domenic> | Thanks for the diagnosing |
| 21:46 | <jgraham> | TabAtkins: Seems like in a docker image just doing a global install is the fast path to the solution |
| 21:46 | <jgraham> | Anyway sleep |
| 21:46 | <TabAtkins> | jgraham: That doesn't help everyone else who might use this package. ^_^ |
| 21:47 | <TabAtkins> | And Domenic already has a fast-path fix for right now. |
| 21:51 | <Domenic> | It does seem like the ecosystem is built on the assumption of global installs with pip, patched over with virtualenv or something. So when you want to do local installs manually a lot of code breaks. |
| 21:57 | <TabAtkins> | Yeah, but that's clumsy and terrible, and I really want a pure-local install for this. So I'm fixing it. |
| 21:57 | <TabAtkins> | The bug is marked "Major" in their bug tracker, so maybe they'll actually fix it themselves. |
| 22:27 | <MikeSmith> | Domenic: sorry about the build breakage |
| 22:28 | <MikeSmith> | well, spec breakage actually |
| 22:29 | <MikeSmith> | I need to figure out why the code isn’t working that I wrote for falling back to the source contents when the hightlighter fails |
| 22:33 | <MikeSmith> | hmm, I can’t reproduce the problem locally, even though I now have Pygments uninstalled (so it should just be using the Pygments copy from the highlighter submodule) |
| 22:47 | <MikeSmith> | nm, managed to reproduce it |
| 22:48 | <TabAtkins> | I've documented the problem in the README for now, with the obvious workaround (install Pygments globally) until I get it fixed. |
| 22:48 | <MikeSmith> | ok cool |
| 22:51 | <MikeSmith> | hmm, but even though I now have the highlighter failing in my environment too, my code for falling back to the source still works. I don’t get any empty <pre>s. Instead I just get the original <pre> contents (unhighlighted) |