| 02:45 | <EveryOS> | Language bindings between Ecmascript and a type-safe language sounds hard. If it were simply reflection, it wouldn't be too hard. But say you want to map a function to a native interface implementation. I can see a few options. The easiest sounding one is to tell the WebIDL binding library how to convert a function to a native interface implementation, say `registerBinding("EventListener", EventListener.class, |
| 02:45 | <EveryOS> | func->((event)->func.call(event)))`, which would effectively tell our IDL code to convert a Javascript Function to the interface required by the language we are binding to. |
| 02:46 | <EveryOS> | But that wiould decrease modularity, by increasing dependency on the IDL Binding library. But I suppose there is no getting away from that, in the first place |
| 02:46 | <EveryOS> | The other option would be to generate and load bytecode on the fly, which would be much harder |
| 11:58 | <ondras> | so, img[crossorigin] - is there an API to detect a CORS error when loading such image (via JS) ? |
| 14:04 | <innovati> | are you allowed to invent custom attribute names for autonomous custom elements (declared in HTML alone, like <hello-world custom></hello-world> with no associated customElements definition)? |
| 14:16 | <devsnek> | how does TLA work with multiple module tags |
| 14:16 | <devsnek> | in the context of this comment anyway https://github.com/tc39/proposal-compartments/issues/27#issuecomment-718772705 |
| 14:26 | <zcorpan> | hsivonen: hmmmmm, will gecko avoid speculatively fetching anything if the encoding is still unknown? |
| 14:27 | <hsivonen> | zcorpan: no, the encoding is always known by the time the non-meta-prescanner tokenizer runs. |
| 14:28 | <hsivonen> | zcorpan: however, it's possible that a charset reload is triggered later, but then that tokenization happens with an encoding that's treated as known |
| 14:28 | <hsivonen> | so what you call "unknown" is considered "late" but Gecko |
| 14:29 | <hsivonen> | and "late" reloads the page |
| 14:29 | <hsivonen> | unless it's a POST response |
| 14:31 | <zcorpan> | hsivonen: ok. with this change https://github.com/web-platform-tests/wpt/pull/24521/commits/08e66e7a5580e1750abea123806a026cd5ec667a , firefox no longer fetches the script in the "page-load" test |
| 14:33 | <hsivonen> | zcorpan: yeah, that look like it's working as expected |
| 14:37 | <zcorpan> | hsivonen: I don't understand why it doesn't speculatively fetch the script |
| 14:39 | <hsivonen> | Hmm. Yeah, the plaintext hasn't really happened at that point. |
| 14:39 | <hsivonen> | I don't have an answer to that. |
| 14:40 | <zcorpan> | hsivonen: ok :) maybe it's a bug then |
| 15:18 | EveryOS | I saw this and thought that there was an error in the browser implementation, but then I realized my battery was at 99% lol |
| 15:18 | <EveryOS> | https://usercontent.irccloud-cdn.com/file/Q2wK8Hgf/image.png |
| 15:19 | <EveryOS> | Huh, IRC formatted my message weirdly |
| 20:52 | <zcorpan> | Lazy-loading fans may be interested in this tpac breakout session tomorrow: https://www.w3.org/2020/10/TPAC/breakout-schedule.html#intersectionobserver |
| 21:52 | <EveryOS> | I haven't had much time to work on that DOM library I was writing (I've been busy). I'm currently on dispatching events, but I am not at home right now because I clock into work in a few minutes. Tomorrow I get a day off, so if I'm lucky, I might make some progress. I'm really wanting to get to the part where I implement nodes. |
| 21:53 | <Domenic> | EveryOS: I assume you're aware of https://github.com/jsdom/jsdom ? |
| 21:56 | <EveryOS> | No, but I am actually using Java, not JS. But I just starred the repo in case it comes in handy. |
| 21:57 | <EveryOS> | Btw, the reason I don't just use the org.w3c package is that it appears outdated. It has methods that the spec specifically says should not exist, and that type of stuff. |
| 21:59 | <EveryOS> | I gotta clock in, so bye |
