| 00:25 | <devsnek> | at that point use a stream |
| 05:22 | <MikeSmith> | should HTMLDocument be considered deprecated? |
| 05:24 | <MikeSmith> | if browsers are required to implement it and there are no plans to ever remove it from the platform, then it seems like it shouldn’t be classified as deprecated |
| 05:27 | <MikeSmith> | sure it’s just specified as an alias for Document, but it’s still specified |
| 06:41 | <annevk> | MikeSmith: where is it classified as such? |
| 06:42 | <annevk> | MikeSmith: there are still some open issues around defining it unfortunately |
| 06:52 | <MikeSmith> | annevk: in MDN and in https://github.com/mdn/browser-compat-data |
| 06:53 | <MikeSmith> | I updated MDN and will make a PR for https://github.com/mdn/browser-compat-data |
| 06:54 | <MikeSmith> | in MDN and in that BCD data, some things seem to be flagged as deprecated just because they’re not useful |
| 06:55 | <MikeSmith> | e.g., NavigatorID: appName and such |
| 06:55 | <MikeSmith> | will fix those too |
| 08:39 | <annevk> | MikeSmith: interesting, I guess someone had opinions |
| 09:51 | <annevk> | https://github.com/httpwg/http-core/issues/148 this took me a while |
| 11:58 | <`slikts> | are there plans to add async iteration to EventTarget |
| 12:02 | <annevk> | `slikts: https://github.com/whatwg/dom/issues/544 |
| 12:03 | <annevk> | `slikts: it's unclear whether that or async iteration is really a good fit though, as event listeners are called synchronously |
| 12:06 | <`slikts> | that is about observables, however; what I meant is async iterables |
| 12:06 | <`slikts> | I strongly believe eventtarget should support the language's native async primitive for streams |
| 12:07 | <`slikts> | I've made a library for adapting streams to async iterables in the interim; I'll share it in a moment after updating its readme |
| 12:07 | <`slikts> | it's like streams api-lite |
| 12:08 | <`slikts> | just because I want to use these things now |
| 12:09 | <annevk> | `slikts: yeah, async interables aren't quite compatible |
| 12:09 | <annevk> | `slikts: does your library handle invoking preventDefault() from a listener? |
| 12:09 | <annevk> | `slikts: (observables have the same issue) |
| 12:10 | <annevk> | `slikts: (and the idea was that both observables and streams would also impl the async iterable protocol) |
| 12:10 | <`slikts> | I've not looked into it that deeply; just in the abstract |
| 12:10 | <`slikts> | I'll read the thread a bit later |
| 12:11 | <annevk> | `slikts: FWIW, I'm very supportive of adding a better API on top of events somehow, the problem is finding something that's the right fit |
| 12:12 | <`slikts> | there won't be a better fit that what's supported natively |
| 12:12 | <`slikts> | in the base language |
| 12:12 | <`slikts> | *than |
| 12:13 | <annevk> | If by that you mean async iterables, see above about it not working with everything events can do... |
| 12:13 | <annevk> | You cannot reframe things on top of a primitive that's a feature mismatch |
| 12:14 | <`slikts> | where there's a will... |
| 12:15 | <`slikts> | I mean, it's already questionable whether observables will make it in since they overlap with async iterables |
| 12:15 | <annevk> | Observables also fail the preventDefault() test |
| 12:15 | <`slikts> | so an alternative async stream primitive with even less mindshare is even less likely |
| 12:16 | <annevk> | Something that works for events would be fine |
| 13:19 | <`slikts> | here's the library: https://github.com/slikts/queueable |
| 13:19 | <`slikts> | still wip; I'm adding documentation, demos |
| 13:46 | <annevk> | So TabAtkins if you're there, do we have that feature yet where you can find who links your spec definition? |
| 13:54 | <yoav> | annevk: Hey! I have a question regarding https://fetch.spec.whatwg.org/#cors-check and the use of origin-or-null. IIUC, a "null" origin would match a case where the request has a tainted origin. Should we match that in RT's TAO processing in https://w3c.github.io/resource-timing/#sec-timing-allow-origin? |
| 13:55 | <annevk> | yoav: what do you currently do? |
| 13:56 | <annevk> | yoav: it’s also for opaque origins |
| 13:56 | <yoav> | annevk: current processing just compares the document's origin to the header value, and fails if they don't match |
| 13:56 | <yoav> | but not special casing "null" |
| 14:00 | <annevk> | yoav: byte-for-byte-comparison is what's supposed to happen |
| 14:00 | <yoav> | OK |
| 14:01 | <annevk> | yoav: so "null" automatically works; it's not specialcased in CORS check either |
| 14:02 | <yoav> | yeah, but IIUC, it's "generated" in https://fetch.spec.whatwg.org/#serializing-a-request-origin |
| 14:02 | <yoav> | which RT is not using (but maybe it should...) |
| 14:03 | <annevk> | yoav: does RT have a request header that carries an origin? |
| 14:04 | <yoav> | not really, the origin comparison are based on the document's origin |
| 14:04 | <yoav> | so we can't use Fetch's algorithm directly (unless we abstract it a bit) |
| 14:05 | <annevk> | yoav: so then you also can't have a tainted origin |
| 14:05 | <Domenic> | annevk: `slikts: see https://stackoverflow.com/questions/39439653/events-vs-streams-vs-observables-vs-async-iterators |
| 14:05 | <annevk> | yoav: which is probably broken |
| 14:05 | <Domenic> | Async iterables are pull, and a bad fit for events |
| 14:05 | <Domenic> | Observables are push, and a reasonable fit for events. They work fine with preventDefault. |
| 14:05 | <annevk> | yoav: if the response was gotten via redirects that did something malicious |
| 14:06 | <`slikts> | Domenic: they're quite nice for certain applications where you could want to skip events, like frames or mouse moves |
| 14:06 | <Domenic> | ReadableStreams are becoming async iterators already. |
| 14:06 | <`slikts> | Domenic: yeah, I follow that issue |
| 14:06 | <`slikts> | the thing about it is that async iterables are in the language now |
| 14:07 | <`slikts> | observables might never be in it |
| 14:07 | <`slikts> | and observables wouldn't have niceties like generator functions and for-await-of |
| 14:07 | <annevk> | Domenic: except for promise-returning methods |
| 14:08 | <`slikts> | also, async iterables aren't just pull, they're pull-push |
| 14:08 | <Domenic> | "in the language" is not an interesting distinction. |
| 14:08 | <annevk> | yoav: open an issue? I can investigate a bit |
| 14:09 | <Domenic> | Those niceties make no sense for events because those niceties are fundamentally pull (e.g. they buffer and operate on promises which breaks preventDefault) |
| 14:09 | <`slikts> | Domenic: it for sure is; having native support, for example, means that engines will focus on optimizations |
| 14:09 | <Domenic> | That's not true |
| 14:09 | <`slikts> | as they have already with async iterables and promises |
| 14:09 | <Domenic> | As an implementer I can guarantee you optimizing user code is just as important |
| 14:09 | <yoav> | annevk: There's https://github.com/w3c/resource-timing/issues/152 which I thought was a small plumbing issue |
| 14:09 | <Domenic> | Built in things start out slow and catch up to user code as we've seen with promises |
| 14:10 | <`slikts> | Domenic: moreover, it's about optics and stability -- a native feature has official approbation and it also won't get yanked away at stage 3 |
| 14:10 | <yoav> | annevk: but now sounds like potentially something to go with the larger scale Fetch integration |
| 14:11 | <`slikts> | Domenic: it's also about familiarity -- iterables and promises are already familiar to many users |
| 14:11 | <Domenic> | Well, can't really help you with your perception. All I can say is we're not going to base events on async iterables since that's a mismatch; it's like basing them on numbers or something else totally inappropriate. |
| 14:12 | <annevk> | yoav: well, some of this can probably be done without all that, but who knows |
| 14:12 | <annevk> | yoav: relying on https://tools.ietf.org/html/rfc6454 is broken too |
| 14:12 | <`slikts> | Domenic: even if it's a mismatch, calling it totally inappropriate is an overstatement |
| 14:13 | <yoav> | Dunno if broken, but definitely seems better to use the same primitives as Fetch |
| 14:13 | <`slikts> | they're somewhat isomorphic concepts, if that makes sense |
| 14:14 | <annevk> | yoav: that entire RFC is replaced by concepts in HTML, URL, and Fetch, but maybe, I guess it depends on the specific usage |
| 14:15 | <`slikts> | observables are just stage 1; it's really hard to sell people on something like that |
| 14:16 | <Domenic> | Observables are a library |
| 14:16 | <annevk> | yoav: but yeah, seems like there are a number of issues here, some more easy to fix than others |
| 14:16 | <Domenic> | You are using a different notion of "isomorphic" than the accepted one |
| 14:16 | <`slikts> | Domenic: it's even harder to sell people on libraries |
| 14:16 | <`slikts> | Domenic: yeah, I qualified it with "somewhat" |
| 14:16 | <Domenic> | Well, not sure why you need to be selling anything here |
| 14:16 | <`slikts> | you need to squint |
| 14:16 | <`slikts> | Domenic: not here; in general |
| 14:17 | <`slikts> | something being "sold" determines if you get to use it in many cases |
| 14:17 | <`slikts> | it's the difference whether you can use it for a hobby project or something more serious |
| 14:17 | <`slikts> | and get other people to collaborate, build an ecosystem, etc. |
| 14:18 | <`slikts> | I'm very entusiastic about reactive programming, but it's just being realistic that observables have a lot of things working against them |
| 14:18 | <`slikts> | async iterables are a way to get a foot into the door |
| 14:19 | <Domenic> | Yeah, I think they need to stand on their own merits, without language support. |
| 14:19 | <`slikts> | since those, too, are declarative and can be used reactively |
| 14:19 | <`slikts> | above all it's about selling the concept of transformative pipeline programming |
| 14:37 | <annevk> | Almost ready to define new infrastructure for HTTP header parsing |
| 14:37 | <annevk> | And then define parsing of all the HTTP headers, to some extent |
| 14:37 | <annevk> | Content-Type and Content-Length at least, I guess |
| 14:41 | <annevk> | This is a little exciting |
| 15:03 | <yoav> | annevk: Any Fetch/HTML WPTs you know if that I can rip off when it comes to testing opaque origins and origin comparison in general? |
| 15:10 | <annevk> | yoav: not offhand, but there is cors/ and fetch/api/cors/ |
| 15:11 | <yoav> | ok, cool. I'll look for it |
| 15:15 | <yoav> | annevk: Would appreciate if you could take a look at https://github.com/w3c/resource-timing/pull/172 and let me know if it seems reasonable |
| 15:16 | <annevk> | yoav: you need document’s origin in DOM, not the type it holds |
| 15:17 | <annevk> | yoav: and origins are always serialized in “ASCII” which is why we dropped that from the term |
| 15:18 | <annevk> | Prolly ok otherwise but omw home on a phone |
| 15:21 | <yoav> | annevk: not sure what you mean by "you need document’s origin in DOM, not the type it holds" |
| 15:22 | <yoav> | (none of this is urgent by the way, so we can continue next week if that's better for you) |
| 16:54 | <annevk> | yoav: you ref concept-origin in HTML, that’s a type |
| 16:55 | <annevk> | yoav: you want the link I gave in the comment |
| 16:55 | <annevk> | yoav: that’s a slot on document |
| 17:24 | <TabAtkins> | annevk: Not yet, no. |
| 17:27 | <annevk> | TabAtkins: Google search found four so far, so there’s that |
| 18:05 | <MikeSmith> | https://stackoverflow.com/questions/52771970/use-fetch-streams-api-to-consume-chunked-data-asynchronously-without-using-recur |
| 18:53 | <annevk> | MikeSmith: so the problem is OOM due to promise allocation? |
| 18:55 | <annevk> | MikeSmith: if true, I guess that is something not all browsers have tried to optimize and was kind of indicated to be a problem of sorts |
| 18:56 | <annevk> | MikeSmith: the difference between the two scenarios is 10x promises afaict |
| 21:44 | <MikeSmith> | annevk: yeah based on “The browser dies at about 50,000 JSON objects” I guess OOM |