| 03:25 | <EveryOS> | I decided to map HTML5 DOM to Java (: Almost finished `Event`. The default implementation that Java provides seems outdated. https://usercontent.irccloud-cdn.com/file/eTliOGYk/image.png |
| 03:46 | <MikeSmith> | EveryOS: that sounds interesting |
| 03:46 | <MikeSmith> | you plan to release it eventually as a library? |
| 03:51 | <EveryOS> | Maybe |
| 03:54 | <MikeSmith> | that would be cool |
| 06:58 | <hsivonen> | zcorpan: At least I expected document.written charset not to be taken into account. Does the document.written charset trigger a late charset reload? I assume it does. And then speculative fetches for that parse should be right. |
| 06:59 | <hsivonen> | zcorpan: from my perspective, document.writing a meta charset is a bad, bad idea |
| 12:30 | <zcorpan> | hsivonen: I haven't tested if it'll trigger a reload. The tests do document.write('<plaintext>') to isolate the effect of speculative parsing |
| 17:27 | <EveryOS> | I was playing around with a chromium-based browser some, when I noticed some weird things about `Window`. |
| 17:29 | <EveryOS> | First off, the spec says that Window should directly extend EventTarget, but in practice, there seems to be a layer of indirection there, with some sort of `WindowProperties` class in between https://usercontent.irccloud-cdn.com/file/0I3EmYpe/image.png |
| 17:29 | <annevk> | EveryOS: IDL should define that |
| 17:30 | <annevk> | EveryOS: Window is quite special (see also WindowProxy, which you mostly interact with) |
| 17:31 | <EveryOS> | From what I can tell, Window directly extends EventTarget https://usercontent.irccloud-cdn.com/file/1sOgl6YN/image.png |
| 17:32 | <EveryOS> | Maybe there is something else I missed elsewhere in the spec |
| 17:35 | <EveryOS> | Oh wait, you mean within the WebIDL spec itself? |
| 17:35 | <EveryOS> | No, it's not there either... https://usercontent.irccloud-cdn.com/file/KO5Fkvxt/image.png |
| 17:39 | <EveryOS> | And then the other thing I was curious about was the lack of methods within Window's prototype, even though they appear on an initialized window. https://usercontent.irccloud-cdn.com/file/sNihFABF/image.png |
| 17:39 | <EveryOS> | Though I am going to guess that also has something to do with `WindowProxy` |
| 17:40 | <EveryOS> | I'm probably just looking at the WindowProxy class and it's just calling itself Window anyways |
| 17:43 | <annevk> | EveryOS: you want to search for stuff IDL does for globals with named properties |
| 17:43 | <annevk> | EveryOS: it doesn't mention the object directly |
| 17:44 | <EveryOS> | Oh, I see |
| 18:01 | <EveryOS> | Ok, yea, that explains everything I noticed |
| 18:01 | <EveryOS> | 1. Any named properties will be exposed on an object in the prototype chain – the named properties object – rather than on the object itself. |
| 18:01 | <EveryOS> | 2. Interface members from the interface will correspond to properties on the object itself rather than on interface prototype objects. |
| 18:02 | <EveryOS> | To be honest, the specs are just so large, there will probably always be something I don't understand |
| 19:27 | <annevk> | It’s too much for one person for sure |
| 22:26 | <EveryOS> | `if EventTarget IS A ServiceWorkerGlobalScopeObject...`How does the "is a" relationship work woth Ecmascript Objects? Do we compare .name, compare .__proto__, or do we use an internal slot which we then compare? https://usercontent.irccloud-cdn.com/file/1J1XuClo/Screenshot_20201027-175903.png |
| 22:28 | <andreubotella> | https://heycam.github.io/webidl/#idl-objects |
| 22:29 | <andreubotella> | I thought there was also a [[PromiseObject]] internal slot, but I might be misremembering |
| 22:30 | <EveryOS> | On the site you linked, it says it is implementation specific, but does suggest using internal state/internal slot. Thanks! |
| 22:31 | <EveryOS> | Sooner or later I should read the WebIDL spec from top to bottom, and take notes |
