| 08:52 | <kochi> | What's the major use case for `view` property of UIEvents? |
| 08:53 | <kochi> | To see if it's in <iframe>? |
| 09:03 | <annevk> | kochi: it's similar to document.defaultView; it dates from a time when they envision a different eventual architecture |
| 09:04 | <annevk> | kochi: I think the idea was that there would be multiple views or some such, each which could handle its own events, but I'm not sure if any implementation ever realized it |
| 09:04 | <kochi> | hmm, then the current motivation to maintaining UIEvents is only for having `details`, then? |
| 09:05 | <annevk> | kochi: https://www.w3.org/TR/2000/REC-DOM-Level-2-Views-20001113/views.html (although that doesn't define the UIEvent thing) |
| 09:05 | <annevk> | kochi: yeah, I think so |
| 09:06 | <annevk> | Interesting, http://www.w3.org/TR/DOM-Level-2-Views redirects to a dated URL; that's an improvement of sorts |
| 09:06 | <kochi> | then, pointer events, which inherits UIEvents define all `detail` are default zero... so it could have been non-UIEvents, then? |
| 09:07 | <annevk> | kochi: yeah, if pointer events doesn't use the interface I don't think it should have inherited from it |
| 09:07 | <annevk> | kochi: maybe that can still be cleaned up? |
| 09:07 | <annevk> | probably not |
| 09:08 | <kochi> | annevk: maybe it's possible, but I don't think anyone appreciates the value of the cleanup at the risk of breaking something. |
| 09:09 | <annevk> | yeah |
| 09:14 | kochi | feels I'm learning something new every day. |
| 09:15 | <annevk> | 😊 that's what keeps it fun |
| 09:17 | <kochi> | exactly. |
| 15:27 | <smaug____> | igrigorik: FYI, per spec performance.onresourcetimingbufferfull is never triggered, since the event is supposed to be fired on Document |
| 15:27 | <smaug____> | and I have no idea why it has bubbles set to true |
| 15:29 | <hsivonen> | what's the preferred way to load a file into an array in memory as part of gtest setup? |
| 15:29 | <hsivonen> | oops. wrong channel |