| 03:55 | <domfarolino> | Anyone happen to know how many concurrent http/1.1 connections the latest versions of firefox/chrome can make? I heard at least one point it was ~6? |
| 04:47 | <annevk> | domfarolino: per origin, sounds about right |
| 04:52 | <domfarolino> | ah |
| 07:37 | <annevk> | JakeA: Domenic: mkwst: did you already consider alternative timing scenarios? |
| 07:37 | <mkwst> | alternative to what? |
| 07:37 | <annevk> | mkwst: to synchronous |
| 07:39 | <mkwst> | How would you expect that to look? |
| 07:39 | <annevk> | mkwst: see last comment in the issue |
| 07:39 | <annevk> | mkwst: well and second-to-last (why is that called second and not first?) |
| 07:41 | <mkwst> | *sigh* I only picked this up because webauthn needed something simple and it looked like folks had already converged on a design, not because I have deep opinions on cancellation (except, of course, about the spelling). I don't think I'm the right guy to define the behavior. |
| 07:42 | <mkwst> | The needs I know about are super-simple, so either synchronous or asynchronous mechanisms could easily fit them. |
| 07:42 | <annevk> | mkwst: good to know, just thought I'd check |
| 07:42 | <mkwst> | I appreciate it! I hope JakeA has more interesting opinions for you! |
| 07:48 | <annevk> | mkwst: either way, I think we're pretty close to success |
| 07:49 | <mkwst> | I hope so! To be clear, I'm willing to do the work to specify what folks want. I just don't have strong opinions about what that might be, nor have I done the background work to gather context on alternative approaches. |
| 07:50 | <annevk> | I somewhat hope Domenic already thought through the timing implications given his long history with promises and will tell us why "asynchronous" isn't important |
| 08:31 | <MikeSmith> | annevk: success https://travis-ci.org/whatwg/encoding/builds/220466241 |
| 08:32 | <MikeSmith> | as far as testing the new checker message-dropping feature |
| 08:32 | <MikeSmith> | and just as far as the “Text run is not in Unicode Normalization Form C.” |
| 08:33 | <annevk> | MikeSmith: great, that looks more like what I was expecting |
| 08:33 | <MikeSmith> | yeah and I’ll deal with the “document appears to be written in Kinyarwanda” upstream |
| 08:34 | <annevk> | MikeSmith: I'm happy with excluding that too |
| 08:34 | <annevk> | MikeSmith: same for private use, which was also intentional |
| 08:34 | <annevk> | Once those two warnings are gone it should succeed I expect |
| 08:34 | <MikeSmith> | yeah |
| 08:35 | <MikeSmith> | and yeah the private-use one I will add to the filter |
| 08:35 | <annevk> | This is really great MikeSmith, much faster turnaround than I could have hoped for |
| 08:36 | <MikeSmith> | yeah I’m glad I managed to get it to work |
| 08:37 | <MikeSmith> | and the Kinyarwanda error, that is a general problem with the language profile for that language and that I realize now must be affecting other checker users. So upstream in the checker source I should either fix that language profile or drop it |
| 08:41 | <MikeSmith> | annevk: btw if you remember anything other issues or PRs you’ve been waiting on me for, lemme know |
| 08:43 | <MikeSmith> | over the weekend, tried to respond to all that I could find (where I had mentions or was assigned) |
| 08:44 | <annevk> | MikeSmith: I think you managed to hit most, I'll let you know if I spot another |
| 08:45 | <MikeSmith> | cheers |
| 08:46 | <annevk> | MikeSmith: actually, I was just looking at one: https://github.com/w3c/web-platform-tests/issues/2669 |
| 08:46 | MikeSmith | looks |
| 08:47 | <MikeSmith> | thanks not sure I got an e-mail notification for that |
| 08:47 | <MikeSmith> | seems like e-mail for some of my GitHub notifications is not reaching me lately |
| 12:13 | <zcorpan> | https://github.com/whatwg/html/issues/1013 - why not use the javascript: scheme here? :-) |
| 12:24 | <annevk> | hehe |
| 12:54 | <zcorpan> | TabAtkins: how can i specify caniuse="" for a css property? <dfn caniuse> in <pre class=propdef> is ignored |
| 12:55 | <MikeSmith> | annevk: OK finally all green at https://github.com/whatwg/encoding/pull/101 |
| 12:55 | <MikeSmith> | > Ran for 12 min 41 sec |
| 12:56 | <MikeSmith> | but given 103 files to check (twice) with the HTML checker I guess that’s not so bad |
| 13:14 | <annevk> | MikeSmith: great! |
| 13:23 | <annevk> | MikeSmith: maybe one thing we could do is to only run the HTML checker for the main index file and not any of the generated files |
| 13:23 | <annevk> | MikeSmith: as the generated files are only rarely modified |
| 13:24 | <annevk> | MikeSmith: of course, that nullifies the need to exclude warnings :/ |
| 13:24 | <gsnedders> | annevk: you could just try running it on files that have changed in a PR |
| 13:58 | <MikeSmith> | annevk: happy to go with whatever you prefer, but I was assuming part of the bigger goal here is to move to having resources.whatwg.org/build/deploy.sh be the common script that each spec/repo uses, and that causes everything under $WEB_ROOT to be checked |
| 13:59 | <MikeSmith> | I guess we could always add a hook to allow any spec/repo .travis.yml to override that recursive $WEB_ROOT html checking and instead just check a given list of files |
| 14:01 | <gsnedders> | is there any way to somehow compare performance.now() with performance.timing.responseStart? |
| 14:06 | <annevk> | MikeSmith: yeah, I guess it's ok, just a bit wasteful |
| 14:07 | <gsnedders> | given performance.timing.responseStart returns ms since the unix epoch |
| 14:08 | <gsnedders> | (can we really not change the behaviour of performance.timing? I'd have expected most people were just comparing values in a single page-load?) |
| 14:35 | <MikeSmith> | annevk: https://stackoverflow.com/questions/43325912/how-to-post-with-application-x-www-form-urlencoded-header-and-urlsearchparams-us |
| 14:37 | <annevk> | MikeSmith: added a comment to OP, seems like a bug in the library |
| 14:45 | <MikeSmith> | annevk: thanks yeah |
| 14:46 | <MikeSmith> | though I think the bug might be in the underlying “github-fetch” code |
| 14:47 | <MikeSmith> | that isomorphic-fetch library seems to be just a thin wrapper around “github-fetch” |
| 14:48 | <annevk> | Ah, okay |
| 14:51 | <annevk> | zcorpan: an interesting thing you might want to test with insertRule is using it on cross-origin stylesheets |
| 14:51 | <annevk> | zcorpan: apparently not all browsers throw |
| 14:51 | <annevk> | zcorpan: opaque cross-origin, not CORS |
| 14:55 | <zcorpan> | annevk: yeah. filed https://github.com/w3c/web-platform-tests/issues/5526 |
| 15:14 | <annevk> | When I run https://w3c-test.org/service-workers/service-worker/client-navigate.https.html Firefox finds five tests and Chrome three |
| 15:34 | <annevk> | Domenic: maybe remove StructuredCloneWithTransfer and add messageerror? Otherwise everyone that uses it needs to update twice |
| 15:35 | <wanderview> | annevk: yea, that test is incorrect and timesout in chrome... I'm fixing it |
| 15:36 | <wanderview> | although in firefox I see 7 tests? |
| 15:37 | <Domenic> | annevk: hmm maybe |
| 15:38 | <annevk> | Domenic: if we don't do that it seems best to tightly couple it with together with SAB |
| 15:38 | <annevk> | Domenic: so you have SAB + messageerror + removal of StructuredCloneWithTransfer |
| 15:38 | <annevk> | Domenic: separate from that we can have 1) rework of worker internals to make agent clusters possible |
| 15:38 | <annevk> | Domenic: 2) definition of agent clusters upon reworked internals |
| 15:38 | <Domenic> | annevk: asynchronous for cancel signals isn't important. It's forced if you are only using ECMAScript and your only way of doing notification is promises. But if you have an event primitive then you're better of sync. It avoids a lot of headaches, e.g. trying to create composition operators (like "follow" or "race"), which is basically impossible with async. |
| 15:40 | <annevk> | Domenic: it's not weird that the cancel signal says cancel and the fetch says TypeError: "invalid URL"? |
| 15:43 | <Domenic> | Hmm why would that happen? |
| 15:44 | <annevk> | Domenic: fetch("https://test:test/";); controller.abort() |
| 15:45 | <annevk> | Domenic: example is outlined in more detail in the whatwg/dom PR |
| 15:45 | <Domenic> | Why isn't fetch validating the URL sync? |
| 15:45 | <annevk> | Domenic: it is? |
| 15:46 | <Domenic> | Ah right |
| 15:46 | <Domenic> | Yeah seems fine then |
| 15:46 | <Domenic> | It's just like any other case of passing the signal to someone who ignores it |
| 15:48 | <Domenic> | even if you did async it'd still be the same errors, just in the other order |
| 15:49 | <annevk> | With async we could .then() the promise returned by fetch() and dispatch cancel from there if the exception was cancel |
| 15:49 | <Domenic> | Sure, but you can do that with sync too |
| 15:49 | <Domenic> | It's pretty unnatural in both cases, IMO |
| 15:50 | <annevk> | What is unnatural? |
| 15:50 | <Domenic> | To wait instead of just calling controller.cancel() immediately |
| 15:50 | <annevk> | That's not what I'm saying? |
| 15:51 | <annevk> | I'm saying that you'd delay updating the signal |
| 15:51 | <Domenic> | Then I don't understand; are we still using the example code `fetch("https://test:test/";, { signal: controller.signal }); controller.abort()` ? |
| 15:52 | <annevk> | Domenic: yeah, but also with an event listener on the signal |
| 15:52 | <Domenic> | Can you type the example then? |
| 15:52 | <annevk> | Domenic: https://github.com/whatwg/dom/pull/434#issuecomment-292869591 |
| 15:53 | <Domenic> | I'm confused, I thought you were saying that you would .then() the promise before doing controller.abort() |
| 15:54 | <annevk> | Domenic: no, I was talking about specification-internals to delay notifying the signal about what happened until we're sure |
| 15:54 | <Domenic> | How does the signal/controller know about fetch() promises? |
| 15:55 | <annevk> | Domenic: fetch() would have that as part of its signal logic |
| 15:55 | <Domenic> | So then it doesn't matter, because by the time fetch() notifies the signal, controller.abort() has already been called |
| 15:55 | <annevk> | Domenic: yes, but if the fetch() didn't end up being aborted because of it, signal wouldn't have had its event fire |
| 15:56 | <Domenic> | why not? controller.abort() was called... |
| 15:57 | <annevk> | Because nothing got aborted |
| 15:57 | <Domenic> | how is that possibly true if controller.abort() is called? |
| 15:58 | <Domenic> | maybe you can write up the alternate spec for controller.abort() you are envisioining |
| 15:58 | <Domenic> | because the spec for it right now is very clear that it would cause the signal to move to the aborted state |
| 15:58 | <Domenic> | and even if you introduce a microtask delay before doing so, that wouldn't change anything |
| 15:59 | <annevk> | Domenic: basically, you'd put fetch() in charge of changing the state, and fetch() only changes the state if aborting itself ended with an AbortError |
| 15:59 | <Domenic> | So you'd remove signal.abort() entirely? |
| 16:00 | <Domenic> | *controller.abort() |
| 16:00 | <annevk> | Domenic: no, that'd still exist to initiate the whole setup |
| 16:01 | <annevk> | controller aborts, fetch aborts, waits for rejection, if it gets a rejection and its an AbortError, changes state of the signal |
| 16:01 | <Domenic> | This sounds very unlike the existing PR, so I'd need to see it written up. I can't imagine how that would work without very tight coupling between fetch and these controller/signal objects. |
| 16:02 | <annevk> | I dunno though, I was just trying to figure out if there was a way to make less code paths run |
| 16:02 | <Domenic> | It may help to re-conceptualize canceled/oncancel as cancelRequested/oncancelrequested |
| 16:02 | <Domenic> | it's just setting a boolean/firing an event to let you know a boolean was set |
| 16:03 | <annevk> | Yeah, maybe that's good enough |
| 16:03 | <Domenic> | then consumers like fetch() can look at that boolean/react to the event and say "ok, i see i was requested to cancel, let me do that" |
| 16:04 | <annevk> | Domenic: see, I didn't realize the event was mostly for JavaScript-implemented consumers of signals |
| 16:04 | <Domenic> | ah ok :) |
| 16:04 | <annevk> | Domenic: I thought the event was for end users of the fetch() API as well |
| 16:04 | <Domenic> | Nah, they just use the fetch() return value. |
| 16:05 | <annevk> | Domenic: I'm not sure about the comments from rbuckton then |
| 16:05 | <annevk> | Domenic: I'll post an update on the issue |
| 16:43 | <gsnedders> | hmm, is it possible to detect background-image loads now using the performance APIs? |
| 16:45 | <annevk> | gsnedders: yeah, if the stylesheet is CORS-same-origin |
| 16:48 | <gsnedders> | I'd totally missed that until now. That's pretty significant. |
| 16:48 | <jyasskin> | annevk: FWIW, I'd like to lobby against including "abortion" anywhere in the abort/cancel spec, even in example code. It's too charged, at least in the U.S. |
| 17:04 | <dmarr> | i wish i could figure out why fetch isn't sending if-none-match headers. it does when i make a call from the console, but not from my webpack-bundled app |
| 17:05 | <annevk> | jyasskin: I thought it might be, hence suggesting "stop" / " halt" |
| 17:05 | <annevk> | jyasskin: but those don't work well with the existing "AbortError" |
| 17:06 | <jyasskin> | annevk: Yep. Even treating "abort" as a noun would be fine with me. |
| 17:06 | <annevk> | jyasskin: having said that, you'd think all the child mutation algorithms would be a little worse |
| 17:06 | <jyasskin> | I personally lean toward using CancelError, CancelToken, CancelController, and then using cancel[l]ation in the non-normative bits of the spec, but I'm not that picky. |
| 17:07 | <jyasskin> | "mutation" isn't a political issue, unless you're way too deep in the X-men. ;) |
| 17:09 | <annevk> | jyasskin: if we're going to use "AbortError" we might as well align all the terms |
| 17:10 | <jyasskin> | Yeah, in that case, it should be "an abort", etc. |
| 17:22 | <dmarr> | what does it mean when my browser gives me a 200 but its from disk cache |
| 17:25 | <annevk> | dmarr: I don't understand the question |
| 17:26 | <dmarr> | annevk: like a GET /foo is 200 but being served from disk cache. Shouldn't that be a 304? |
| 17:26 | <dmarr> | or I guess what are the cases where something will 200 but be a cached response |
| 17:27 | <annevk> | dmarr: unless it was not a 200/304 to begin with, you'll almost always get a 200 through fetch()/XHR |
| 17:32 | <dmarr> | annevk: I get a 304 as expected when using the if-none-match header with a value of the current etag from the server |
| 17:32 | <dmarr> | but on other requests not using if-none-match i get 200 from disk - I guess thats normal |
| 17:33 | <annevk> | dmarr: yeah, there's a few ways to get the 304 back, but by default it's always "flattened" into a 200 |
| 17:43 | <annevk> | Hmm, so dedicated/shared workers have pointers to 1) one or more documents 2) zero or more child workers 3) a parent (not covered by HTML) 4) a browsing context (for the purpose of checking if script is enabled; does that really live there?) |
| 17:43 | <annevk> | Seems so messy |
| 17:45 | <wanderview> | annevk: implementation-wise I am thinking of making Workers reference Client objects |
| 17:45 | <wanderview> | should be easy for the SharedWorker case |
| 17:45 | <wanderview> | less sure about dedicated workers |
| 17:46 | <wanderview> | so SharedWorker would have an array of attached Client objects instead of an array of attached documents |
| 17:47 | <wanderview> | might need a bit of work-around logic to make it handle the replaced about:blank document case since the Client is the environment instead of the document |
| 17:49 | <annevk> | wanderview: hmm, the replaced about:blank document case makes me wonder if it's not global objects already |
| 17:49 | <wanderview> | annevk: we could probably make it so... its got relatively low usage and a bit of a corner case |
| 17:49 | <annevk> | Guess I should write tests, but not today |
| 17:58 | <aklein> | annevk: I'm trying to grok your comment on https://github.com/whatwg/dom/pull/434#issuecomment-292696490 about cancel tokens not meeting the fetch use case. what do you mean by "we need objects that we can extend"? |
| 18:00 | <dmarr> | annevk: so the case where no if-none-match is sent in the request and a cached 200 comes back, is there another response header that causes that to happen? My server is sending etag, cache-control, date |
| 18:53 | <Domenic> | annevk: I believe bz has commented a few times that the scripting-enabled checks in the spec don't match impls :-/ |
| 19:21 | <annevk> | dmarr: custom if-none-match? |
| 19:22 | <annevk> | aklein: what is the shape of a theoretical cancel token? Can it do events? |
| 19:23 | <annevk> | aklein: the signal we have is also going to be able to carry priority data and other such things |
| 19:24 | <annevk> | Domenic: did he say what impls do? I guess we need to make it official as long as noscript is around? Could also just remove the concept… |
| 19:25 | <jyasskin> | annevk: Dumb question: If we have the ES AbortSignal.register(callback) function, what's the benefit of using events instead? |
| 19:25 | <Domenic> | annevk: context? |
| 19:25 | <botie> | hmmm... context is https://github.com/validator/validator/issues/284 |
| 19:26 | <annevk> | jyasskin: you can have a different event for priorities? |
| 19:26 | <jyasskin> | aklein: https://github.com/whatwg/fetch/issues/447#issuecomment-281731850 has the FetchController design. It'd want to be a subclass of the AbortController, or have AbortController mixed into it. |
| 19:27 | <jyasskin> | annevk: Ah, instead of having multiple signals, you'd have one signal with multiple events. |
| 19:27 | <annevk> | Domenic: your statement about scripting-enabled |
| 19:28 | <Domenic> | annevk: ah right. Let me dig it up. I think most UAs still have a toggle, someone showed me where Chrome's was recently. |
| 19:28 | <annevk> | jyasskin: yes, a FetchSignal tracks a bunch of bits and can then be reused across fetches |
| 19:28 | <Domenic> | Yeah and FetchSignal needs EventTarget anyway for other events. |
| 19:31 | <Domenic> | Hmm found https://github.com/whatwg/html/issues/1580 so far, not the issue I was thinking of though... |
| 19:34 | <jyasskin> | annevk/Domenic: If the ES system gave AbortSignal an onabort(callback) function instead of a register(callback) function (https://github.com/rbuckton/prex/blob/master/docs/cancellation.md#tokenregistercallback), would that be sufficient to let FetchSignal extend it as you want? |
| 19:34 | <Domenic> | No |
| 19:35 | <Domenic> | Because the inheritance hierarchy wouldn't work |
| 19:35 | <Domenic> | We need to inherit from EventTarget, not from ESAbortSignal |
| 19:35 | <jyasskin> | Oh, because EventTarget is a base class instead of a mixin. :( |
| 19:35 | <Domenic> | And it's a strictly worse experience for our users to have two ways of registering events, anyway |
| 19:35 | <Domenic> | Better to just use addEventListener for both abort and the other things |
| 19:36 | <Domenic> | There's no benefit to putting this in ES without syntax (e.g. my old third state proposal) |
| 19:39 | <jyasskin> | Sharing code with Node would be a benefit, although not to pure web users, and I see that moving away from addEventListener would be painful. aklein, is that convincing to the ES folks? |
| 19:40 | <Domenic> | node can share code, just like with fetch, they just need to copy the API over |
| 19:40 | <Domenic> | https://github.com/matthew-andrews/isomorphic-fetch/ etc. |
| 19:41 | <jyasskin> | Domenic: They'd copy the AbortSignal implementation including the EventTarget implementation, right? |
| 19:42 | <Domenic> | Yeah, or they'd make their own using EventEmitter, their choice |
| 19:44 | <jyasskin> | Domenic: Thanks. |
| 19:44 | <annevk> | Now that observables are gone we could revisit a better EventTarget and maybe get Node on board |
| 19:44 | <annevk> | With full compat on our side of course |
| 19:46 | <Domenic> | annevk: it's actually on my quarterly goal to write a spec for event-delegation and and event "namespaces" (https://github.com/whatwg/dom/issues/215 and https://github.com/whatwg/dom/issues/208) as first steps in exploring their feasibility and getting that rolling |
| 19:47 | <annevk> | Cool cool |
| 19:47 | <TabAtkins> | Ugh, observables got dropped? |
| 19:48 | <TabAtkins> | Events suck. :( |
| 19:59 | <aklein> | annevk: where do you see observables being gone? |
| 20:28 | <Domenic> | TabAtkins: thoughts on https://github.com/whatwg/html/pull/2517 ? |
| 20:30 | <TabAtkins> | Domenic: You want the attr-value type file:///usr/local/google/home/tabatkins/bikeshed/docs/index.html#dfn-types |
| 20:30 | <TabAtkins> | Whoops, one sec for better links |
| 20:31 | <TabAtkins> | https://tabatkins.github.io/bikeshed/#dfn-types |
| 20:33 | <Domenic> | TabAtkins: ah makes sense, so the for is... for="link/rel"? |
| 20:33 | <TabAtkins> | Yup |
| 20:33 | <TabAtkins> | Then <{link/rel/serviceworker}> |
| 20:34 | <TabAtkins> | I think <{rel/serviceworker}> might work too? I forget how strict I am with that shorthand. |
| 20:36 | <Domenic> | Awesome, thanks |
| 21:03 | <aklein> | jyasskin: I'm unclear as to why events are now considered a requirement of this API, while they weren't when the plan of record was to wait for whatever TC39 came up with. but I do think I understand annevk's comment about "extending" now |
| 21:31 | <wanderview> | annevk: JakeA: that cross-origin referer footgun in new Request() hit mobile twitter :-( https://bugzilla.mozilla.org/show_bug.cgi?id=1352101#c10 |
| 21:31 | <wanderview> | our fix is in FF54... has chrome started implementing the spec change yet? |