is ignored [05:55:06.0000] annevk: OK finally all green at https://github.com/whatwg/encoding/pull/101 [05:55:19.0000] > Ran for 12 min 41 sec [05:56:07.0000] but given 103 files to check (twice) with the HTML checker I guess that’s not so bad [06:14:56.0000] MikeSmith: great! [06:23:50.0000] 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 [06:23:58.0000] MikeSmith: as the generated files are only rarely modified [06:24:12.0000] MikeSmith: of course, that nullifies the need to exclude warnings :/ [06:24:29.0000] annevk: you could just try running it on files that have changed in a PR [06:58:07.0000] 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 [06:59:43.0000] 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 [07:01:00.0000] is there any way to somehow compare performance.now() with performance.timing.responseStart? [07:06:08.0000] MikeSmith: yeah, I guess it's ok, just a bit wasteful [07:07:49.0000] given performance.timing.responseStart returns ms since the unix epoch [07:08:12.0000] (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?) [07:35:01.0000] annevk: https://stackoverflow.com/questions/43325912/how-to-post-with-application-x-www-form-urlencoded-header-and-urlsearchparams-us [07:37:33.0000] MikeSmith: added a comment to OP, seems like a bug in the library [07:45:52.0000] annevk: thanks yeah [07:46:28.0000] though I think the bug might be in the underlying “github-fetch” code [07:47:20.0000] that isomorphic-fetch library seems to be just a thin wrapper around “github-fetch” [07:48:43.0000] Ah, okay [07:51:02.0000] zcorpan: an interesting thing you might want to test with insertRule is using it on cross-origin stylesheets [07:51:10.0000] zcorpan: apparently not all browsers throw [07:51:29.0000] zcorpan: opaque cross-origin, not CORS [07:55:44.0000] annevk: yeah. filed https://github.com/w3c/web-platform-tests/issues/5526 [08:14:12.0000] When I run https://w3c-test.org/service-workers/service-worker/client-navigate.https.html Firefox finds five tests and Chrome three [08:34:54.0000] Domenic: maybe remove StructuredCloneWithTransfer and add messageerror? Otherwise everyone that uses it needs to update twice [08:35:54.0000] annevk: yea, that test is incorrect and timesout in chrome... I'm fixing it [08:36:25.0000] although in firefox I see 7 tests? [08:37:22.0000] annevk: hmm maybe [08:38:01.0000] Domenic: if we don't do that it seems best to tightly couple it with together with SAB [08:38:20.0000] Domenic: so you have SAB + messageerror + removal of StructuredCloneWithTransfer [08:38:38.0000] Domenic: separate from that we can have 1) rework of worker internals to make agent clusters possible [08:38:47.0000] Domenic: 2) definition of agent clusters upon reworked internals [08:38:55.0000] 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. [08:40:40.0000] Domenic: it's not weird that the cancel signal says cancel and the fetch says TypeError: "invalid URL"? [08:43:40.0000] Hmm why would that happen? [08:44:58.0000] Domenic: fetch("https://test:test/"); controller.abort() [08:45:21.0000] Domenic: example is outlined in more detail in the whatwg/dom PR [08:45:25.0000] Why isn't fetch validating the URL sync? [08:45:55.0000] Domenic: it is? [08:46:06.0000] Ah right [08:46:25.0000] Yeah seems fine then [08:46:34.0000] It's just like any other case of passing the signal to someone who ignores it [08:48:34.0000] even if you did async it'd still be the same errors, just in the other order [08:49:31.0000] With async we could .then() the promise returned by fetch() and dispatch cancel from there if the exception was cancel [08:49:44.0000] Sure, but you can do that with sync too [08:49:57.0000] It's pretty unnatural in both cases, IMO [08:50:12.0000] What is unnatural? [08:50:33.0000] To wait instead of just calling controller.cancel() immediately [08:50:55.0000] That's not what I'm saying? [08:51:10.0000] I'm saying that you'd delay updating the signal [08:51:34.0000] Then I don't understand; are we still using the example code `fetch("https://test:test/", { signal: controller.signal }); controller.abort()` ? [08:52:03.0000] Domenic: yeah, but also with an event listener on the signal [08:52:35.0000] Can you type the example then? [08:52:58.0000] Domenic: https://github.com/whatwg/dom/pull/434#issuecomment-292869591 [08:53:52.0000] I'm confused, I thought you were saying that you would .then() the promise before doing controller.abort() [08:54:24.0000] Domenic: no, I was talking about specification-internals to delay notifying the signal about what happened until we're sure [08:54:37.0000] How does the signal/controller know about fetch() promises? [08:55:00.0000] Domenic: fetch() would have that as part of its signal logic [08:55:15.0000] So then it doesn't matter, because by the time fetch() notifies the signal, controller.abort() has already been called [08:55:57.0000] Domenic: yes, but if the fetch() didn't end up being aborted because of it, signal wouldn't have had its event fire [08:56:19.0000] why not? controller.abort() was called... [08:57:01.0000] Because nothing got aborted [08:57:43.0000] how is that possibly true if controller.abort() is called? [08:58:08.0000] maybe you can write up the alternate spec for controller.abort() you are envisioining [08:58:27.0000] because the spec for it right now is very clear that it would cause the signal to move to the aborted state [08:58:35.0000] and even if you introduce a microtask delay before doing so, that wouldn't change anything [08:59:48.0000] 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 [08:59:56.0000] So you'd remove signal.abort() entirely? [09:00:02.0000] *controller.abort() [09:00:18.0000] Domenic: no, that'd still exist to initiate the whole setup [09:01:06.0000] controller aborts, fetch aborts, waits for rejection, if it gets a rejection and its an AbortError, changes state of the signal [09:01:54.0000] 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. [09:02:00.0000] I dunno though, I was just trying to figure out if there was a way to make less code paths run [09:02:29.0000] It may help to re-conceptualize canceled/oncancel as cancelRequested/oncancelrequested [09:02:51.0000] it's just setting a boolean/firing an event to let you know a boolean was set [09:03:07.0000] Yeah, maybe that's good enough [09:03:09.0000] 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" [09:04:20.0000] Domenic: see, I didn't realize the event was mostly for JavaScript-implemented consumers of signals [09:04:31.0000] ah ok :) [09:04:42.0000] Domenic: I thought the event was for end users of the fetch() API as well [09:04:58.0000] Nah, they just use the fetch() return value. [09:05:13.0000] Domenic: I'm not sure about the comments from rbuckton then [09:05:27.0000] Domenic: I'll post an update on the issue [09:43:27.0000] hmm, is it possible to detect background-image loads now using the performance APIs? [09:45:45.0000] gsnedders: yeah, if the stylesheet is CORS-same-origin [09:48:04.0000] I'd totally missed that until now. That's pretty significant. [09:48:39.0000] 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. [10:04:56.0000] 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 [10:05:26.0000] jyasskin: I thought it might be, hence suggesting "stop" / " halt" [10:05:45.0000] jyasskin: but those don't work well with the existing "AbortError" [10:06:05.0000] annevk: Yep. Even treating "abort" as a noun would be fine with me. [10:06:42.0000] jyasskin: having said that, you'd think all the child mutation algorithms would be a little worse [10:06:58.0000] 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. [10:07:20.0000] "mutation" isn't a political issue, unless you're way too deep in the X-men. ;) [10:09:51.0000] jyasskin: if we're going to use "AbortError" we might as well align all the terms [10:10:42.0000] Yeah, in that case, it should be "an abort", etc. [10:22:18.0000] what does it mean when my browser gives me a 200 but its from disk cache [10:25:55.0000] dmarr: I don't understand the question [10:26:27.0000] annevk: like a GET /foo is 200 but being served from disk cache. Shouldn't that be a 304? [10:26:44.0000] or I guess what are the cases where something will 200 but be a cached response [10:27:50.0000] dmarr: unless it was not a 200/304 to begin with, you'll almost always get a 200 through fetch()/XHR [10:32:14.0000] annevk: I get a 304 as expected when using the if-none-match header with a value of the current etag from the server [10:32:53.0000] but on other requests not using if-none-match i get 200 from disk - I guess thats normal [10:33:02.0000] dmarr: yeah, there's a few ways to get the 304 back, but by default it's always "flattened" into a 200 [10:43:23.0000] 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?) [10:43:28.0000] Seems so messy [10:45:15.0000] annevk: implementation-wise I am thinking of making Workers reference Client objects [10:45:24.0000] should be easy for the SharedWorker case [10:45:35.0000] less sure about dedicated workers [10:46:05.0000] so SharedWorker would have an array of attached Client objects instead of an array of attached documents [10:47:17.0000] 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 [10:49:11.0000] wanderview: hmm, the replaced about:blank document case makes me wonder if it's not global objects already [10:49:43.0000] annevk: we could probably make it so... its got relatively low usage and a bit of a corner case [10:49:57.0000] Guess I should write tests, but not today [10:58:39.0000] 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"? [11:00:26.0000] 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 [11:53:18.0000] annevk: I believe bz has commented a few times that the scripting-enabled checks in the spec don't match impls :-/ [12:21:25.0000] dmarr: custom if-none-match? [12:22:30.0000] aklein: what is the shape of a theoretical cancel token? Can it do events? [12:23:39.0000] aklein: the signal we have is also going to be able to carry priority data and other such things [12:24:45.0000] 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… [12:25:10.0000] annevk: Dumb question: If we have the ES AbortSignal.register(callback) function, what's the benefit of using events instead? [12:25:55.0000] annevk: context? [12:25:55.0000] hmmm... context is https://github.com/validator/validator/issues/284 [12:26:10.0000] jyasskin: you can have a different event for priorities? [12:26:30.0000] 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. [12:27:37.0000] annevk: Ah, instead of having multiple signals, you'd have one signal with multiple events. [12:27:39.0000] Domenic: your statement about scripting-enabled [12:28:14.0000] annevk: ah right. Let me dig it up. I think most UAs still have a toggle, someone showed me where Chrome's was recently. [12:28:20.0000] jyasskin: yes, a FetchSignal tracks a bunch of bits and can then be reused across fetches [12:28:52.0000] Yeah and FetchSignal needs EventTarget anyway for other events. [12:31:58.0000] Hmm found https://github.com/whatwg/html/issues/1580 so far, not the issue I was thinking of though... [12:34:42.0000] 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? [12:34:58.0000] No [12:35:06.0000] Because the inheritance hierarchy wouldn't work [12:35:23.0000] We need to inherit from EventTarget, not from ESAbortSignal [12:35:37.0000] Oh, because EventTarget is a base class instead of a mixin. :( [12:35:39.0000] And it's a strictly worse experience for our users to have two ways of registering events, anyway [12:35:51.0000] Better to just use addEventListener for both abort and the other things [12:36:18.0000] There's no benefit to putting this in ES without syntax (e.g. my old third state proposal) [12:39:33.0000] 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? [12:40:10.0000] node can share code, just like with fetch, they just need to copy the API over [12:40:37.0000] https://github.com/matthew-andrews/isomorphic-fetch/ etc. [12:41:58.0000] Domenic: They'd copy the AbortSignal implementation including the EventTarget implementation, right? [12:42:18.0000] Yeah, or they'd make their own using EventEmitter, their choice [12:44:13.0000] Domenic: Thanks. [12:44:14.0000] Now that observables are gone we could revisit a better EventTarget and maybe get Node on board [12:44:55.0000] With full compat on our side of course [12:46:29.0000] 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 [12:47:14.0000] Cool cool [12:47:59.0000] Ugh, observables got dropped? [12:48:08.0000] Events suck. :( [12:59:38.0000] annevk: where do you see observables being gone? [13:28:15.0000] TabAtkins: thoughts on https://github.com/whatwg/html/pull/2517 ? [13:30:42.0000] Domenic: You want the attr-value type file:///usr/local/google/home/tabatkins/bikeshed/docs/index.html#dfn-types [13:30:49.0000] Whoops, one sec for better links [13:31:06.0000] https://tabatkins.github.io/bikeshed/#dfn-types [13:33:20.0000] TabAtkins: ah makes sense, so the for is... for="link/rel"? [13:33:29.0000] Yup [13:33:56.0000] Then <{link/rel/serviceworker}> [13:34:22.0000] I think <{rel/serviceworker}> might work too? I forget how strict I am with that shorthand. [13:36:50.0000] Awesome, thanks [14:03:27.0000] 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 [14:31:26.0000] annevk: JakeA: that cross-origin referer footgun in new Request() hit mobile twitter :-( https://bugzilla.mozilla.org/show_bug.cgi?id=1352101#c10 [14:31:56.0000] our fix is in FF54... has chrome started implementing the spec change yet? 2017-04-11 [18:16:48.0000] botie, forget context [18:16:48.0000] MikeSmith: I forgot context [18:21:47.0000] TabAtkins: Domenic thanks for the tip on <{link/rel/serviceworker}>, will update the https://github.com/whatwg/html/pull/2517#issuecomment-293070580 PR right now [18:22:25.0000] Bikeshed rocks [18:24:13.0000] /me 's entry settings object alarm goes off (re: wanderview's link) [18:24:50.0000] Domenic: that error message was written based on old spec text I believe [18:25:01.0000] and we haven [18:25:19.0000] we haven't implemented the new spec text yet for the multi-global tests you wrote [21:37:19.0000] 有人吗？ [21:37:43.0000] anyone there？ [22:12:53.0000] aklein: we waited for two years on TC39 not looking at the problem much ourselves [22:13:50.0000] aklein: when we then started looking after third state et al failed we found several things that could be tightly coupled in a rather nice way [22:14:24.0000] aklein: and would not have been possible with the TC39 proposals [22:16:05.0000] aklein: and then a subset of that functionality got extracted as a set of base classes since it turned out we did want it in multiple places [22:16:27.0000] aklein: that last one was rather recent [22:17:28.0000] wanderview: nothing I can help with right? I believe we removed all the exception "footguns" [23:39:18.0000] https://github.com/Fyrd/caniuse/issues/885#issuecomment-293136872 [23:40:01.0000] https://caniuse.com/ 🎉 [01:46:12.0000] It seems really slow [02:03:56.0000] yeah [02:04:00.0000] same here [02:04:04.0000] loads slow [03:48:10.0000] MikeSmith: do you still care about the HTML4 validation modes in v.nu code? [03:50:01.0000] hsivonen: nope [03:50:13.0000] MikeSmith: thanks [03:50:27.0000] planning to yank them? [03:50:34.0000] if so, happy to help [03:50:37.0000] MikeSmith: very possibly [03:50:46.0000] OK [03:51:09.0000] I'm currently trying to make the parser go faster, and I'm wondering if I should keep the HTML4-related flags on the attribute names [03:51:26.0000] ah [03:51:47.0000] yeah especially if it would be a performance gain, no reason to keep them [03:58:19.0000] good times. the parser knows about https://msdn.microsoft.com/en-us/library/ms533706(v=vs.85).aspx Can't even remember why. [04:01:06.0000] apparently because HTML 4.01 reserves it for future use! [04:02:10.0000] dataformatas I always read that as "data formatas", not "data format as" [04:02:38.0000] me too [04:03:14.0000] veryverythickmathspace [04:39:18.0000] Domenic: your definition of "agent" was wrong too [04:39:36.0000] Domenic: a user agent is allowed to have one event loop for all its browsing contexts [04:40:13.0000] Domenic: do we just want to make that disallowed since it cannot be observed if a user agent does that or do we actually want to work around it some other way? [05:02:07.0000] Domenic: what ECMAScript calls the "executing thread" is what we call the event loop [06:04:02.0000] annevk: right, I was just mentioning it hit a relatively large site unfortunately [06:04:33.0000] and I guess asking JakeA if they had plans to impl the footgun fixes [06:06:57.0000] I'll chase it [06:08:24.0000] maybe its fixed in canary? I only tested in release chrome... although I don't remember seeing a chromium issue for it [07:04:07.0000] Reminder to self: don't volunteer for seemingly trivial tasks [07:14:12.0000] JakeA: I have more detailed nits on the Abort stuff I think from a quick skim, but I'll wait a bit for more high-level feedback first [07:14:59.0000] JakeA: overall though it seems ready enough to me to determine implementation interest and write tests [07:15:51.0000] annevk: Cool. I just pushed some more to the fetch branch. Will fix the nits [07:17:14.0000] JakeA: I guess I would like to have it explained why we normalize to FetchSignal [07:17:34.0000] JakeA: not in spec, here or in a comment on the PR is fine [07:18:35.0000] annevk: I was worried that devs might write code expecting request.signal to be a particular type, and get caught out when it turns out to be another type for a rare code path [07:19:08.0000] I guess the signal doesn't have methods though [07:19:55.0000] But if they expect .priority to be there & be a number [07:20:00.0000] JakeA: if they don't pass one in themselves it'll just be null, no? [07:20:31.0000] JakeA: and if they pass one in themselves it should be somewhat clear what they get [07:20:39.0000] annevk: I was thinking of cases where they get the request object from elsewhere [07:21:24.0000] JakeA: yeah okay, I guess it's okay [07:21:59.0000] annevk: should I remove FetchController? [07:22:05.0000] I guess we don't need it [07:22:43.0000] JakeA: you cannot get a FetchSignal otherwise and that would mean you always get an allocation each time you invoke fetch() with a signal [07:22:44.0000] Hah, although if we start with FetchSignal without .priority, developers are going to have to test for its existence anyway [07:22:54.0000] JakeA: good point [07:23:01.0000] JakeA: maybe just drop it entirely then [07:23:22.0000] annevk: agreed, I'll remove the casting [07:23:34.0000] pffft wish I'd figured that out early [07:24:00.0000] Well, you've learned something I'm sure [07:24:16.0000] \o/ [07:47:05.0000] the only way Artur Janc could have a cooler name is if his first name were Antti [09:04:31.0000] annevk: I think it might be time to disallow that because SABs make it observable [09:04:49.0000] It seems related to how I had to delete the sequential consistency guarantee from early in the spec [09:39:29.0000] Domenic: 1) apparently an Agent is not an event loop, but maybe SAB still makes it observable somehow? If so, that seems bad? [09:39:39.0000] I am still pretty sure an agent is an event loop. [09:39:58.0000] Domenic: I just talked at length with lth in jslang and he told me that was wrong [09:40:04.0000] yeah i think he is wrong :) [09:40:13.0000] sigh [09:40:21.0000] i know :-/ [09:40:32.0000] it was very surprising to wake up to find out the creator of agents thinks they are just redundant with realms [09:40:43.0000] Domenic: 2) I noticed that JavaScript has consistency requirements for Agent clusters and when I ported that requirement over to HTML WebKit folks blocked it [09:41:04.0000] yeah, those were unilaterally added by lth without cross-browser agreement i guess [09:41:23.0000] we should probably raise that in tc39 [09:41:25.0000] Domenic: in particular, those agent cluster requirements would apply to when you kill workers and such [09:41:39.0000] since i don't think the jsc folks realized what was being put in the spec [09:41:44.0000] and they should talk to their webkit teammates [09:41:48.0000] more sigh [09:42:11.0000] If someone wants to introduce a new platform feature they should really work it through all the way [09:42:33.0000] We should try to make that a requirement of sorts, you can't just land something in ecma262 and call it a day [09:42:48.0000] At least not something with obvious Host implications [09:47:06.0000] annevk: re: cancellation. hypothetically, had ES shipped some cancellation thing a year ago, would fetch use it? or would you have said "no, we need this to mesh well with events"? [09:47:41.0000] aklein: I suspect we would have used it [09:48:09.0000] aklein: but a year ago we also had a pretty poor understanding of what this could look like [09:48:48.0000] aklein: so we might have just gone down the fastline of adding cancelation since folks are waiting on that (and have been for over two years now) [09:50:34.0000] annevk: oh, other question from yesterday. you said "observables are gone"...what was that in reference to? [09:51:51.0000] aklein: I forgot who I got that from, but I got the distinct impression that it didn't have sufficient interest from implementers and the only host consumer might be events, and we could also solve events on our own [09:52:18.0000] aklein: I got the impression there was not sufficient need to add it as a primitive to the core language [09:52:40.0000] aklein: and so browsers wouldn't ship it [09:53:08.0000] annevk: huh, I wonder if that's what you took away from our conversation [09:53:46.0000] aklein: could be or maybe from Domenic, my memory is not super clear on it so maybe I'm just wrong [09:54:07.0000] annevk: myself, as an implementer, I'm certainly cautious to add new core things to the language. but I think there is still interest in the committee, including at least one implementer [09:54:09.0000] (not that memory is ever clear...) [09:55:51.0000] aklein: okay, I have been blocking a bit on it in DOM as well as earlier indications TC39 might do some event thing (that was long ago though), but nothing materialized thus far and it does seem nice to make the event API a little better soonish [09:56:02.0000] aklein: we got most of jQuery covered [09:56:43.0000] annevk: Jafar is the person to talk to about whether it's dead or not. he hasn't been able to make it to the last few meetings, so it keeps getting dropped off the agenda. [09:57:30.0000] annevk: but this cancellation is indeed an interesting place to re-raise the event question [10:06:56.0000] aklein: it's somewhat problematic that stuff needs to be actively lobbied through a committee and host concerns are generally not cared much for [10:09:06.0000] I guess that's too unspecific, but I've noticed this with jobs, SharedArrayBuffer (see what's an agent?), and maybe also things like observables [10:09:40.0000] You really can only make a case when you're in the room or have someone in the room that knows the full argument [10:27:31.0000] Domenic: I guess the silver lining is that even though I based things on settings objects, what I wrote down is easily convertible and more accurate in the worker edge cases (I think!) [10:28:35.0000] Domenic: but with awb's comment I'm becoming somewhat surprised I've led myself be deluded that much, since I was involved in a bunch of the previous discussions [10:37:01.0000] annevk: awb's comment seems about right to me. In particular the "The realms in the set are private to the Agent and may not be accessible to any other agent." seems to break the 1:1ness [10:37:23.0000] (as I expected) [10:46:20.0000] Domenic: yeah, I guess I just thought when lth told me that they revamped the whole concept somehow [10:46:45.0000] Domenic: anyway, glad I filed the bug [10:47:06.0000] yeah, agreed [10:48:18.0000] Domenic: I also like awb's suggestions of actually defining the internals in much more detail [10:48:35.0000] yeah honestly i thought at least some of those were already defined but i guess i haven't read the agents spec recently [10:48:57.0000] it sounds like people have great misunderstanding about passive listeners [10:49:16.0000] that they somehow magically make performance good everywhere [10:50:14.0000] I wonder what the source on https://twitter.com/antimattur/status/851850917662117888 is [10:53:03.0000] smaug: oh my, not totally unexpected, but still [10:58:46.0000] Domenic: let me know when you find it [11:04:26.0000] annevk: I don't think there's any general fix here. cross-cutting concerns are cross-cutting. this comes up in plenty of places other than ES <-> HTML/DOM [11:52:30.0000] annevk: in this case, I suspect that Lars's "document" just doesn't match your concept of "document". need to go catch up on the thread [12:52:11.0000] aklein: I recommend reading the jslang backlog, we discussed it in depth [13:01:20.0000] annevk: yeah, I see that this conversation is split across several media [13:12:47.0000] annevk: having read all that, still seems like this is a miscommunication, not a fundamental flaw. hopefully the github issue will help sort out the communication issues [13:13:11.0000] yes, i am also leaning toward miscommunication [14:57:46.0000] TabAtkins or anyone: is there no default "W3C" boilerplate? In particular I am pretty sure CC0/OWFa is not correct when I put "Group: W3C" [14:57:55.0000] There is not, no. [14:58:03.0000] So you're just getting the default boilerplate with that group. [14:58:48.0000] hmm so if i want to write a spec without a group i need to submit a bikeshed PR for that group adding all the boilerplate? :-/ [14:58:50.0000] (There's no such thing as a generic W3C spec; everything's produced under a group.) [14:59:07.0000] s/"without a group"/for a group that isn't in Bikeshed's tree yet [14:59:08.0000] Nah, you can add the boilerplate locally in your spec folder. [14:59:26.0000] Well OK, that's slightly better, but still a lot of yak-shaving [14:59:43.0000] I guess I don't have any better suggestion though, just complaints [14:59:46.0000] It's... the minimum amount to actually publish a valid W3C spec? [15:00:11.0000] I guess the issue is I don't want to publish a valid W3C spec at this point, I just want to publish something that isn't under a license that'll get me in trouble. [15:00:26.0000] (in trouble when I do want to go through all the work of actually publishing, that is) [15:00:41.0000] Swap out the copyright.include locally, then. Just put in an "all rights reserved" or something for now. [15:00:43.0000] Domenic: Which group is it in? Can you use WICG? [15:00:48.0000] Always easy to loosen things. [15:00:48.0000] jyasskin: web payments [15:00:58.0000] TabAtkins: copyright.include, roger roger. [15:01:18.0000] Domenic: And you can do that actually inside your spec. [15:01:28.0000]

should work. [15:07:43.0000] Seem to be in good shape. Thanks as always for the help. [15:12:07.0000] TabAtkins: wasn't there a way to tell Bikeshed how much indentation I plan on using? Can't find it searching for "indent" in the docs [15:53:57.0000] Domenic: Ah, hm, it's not documented. It's "Indent: " [16:06:43.0000] Domenic: have a moment for a question or two about the new extended attributes on types in WebIDL? [16:06:58.0000] might be the wrong dominic :( [16:07:23.0000] nope, got it right! [16:09:38.0000] basically, the question is, int the case of something like [16:09:57.0000] [Clamp] attribute long foo; [16:10:36.0000] should the [Clamp] be in annotated type of foo [16:11:19.0000] The https://heycam.github.io/webidl/#idl-type-extended-attribute-associated-with algorithm stiplilates that is should for union, argument, dictionary and typedef productions, but not for attributes [16:12:28.0000] tobie: perhaps you know [16:27:01.0000] weinig: back from dinner! Let's see [16:27:09.0000] Domenic: hi there [16:27:23.0000] weinig: so the idea is that that is now an error since [Clamp] cannot be used except on types. We need to go update all the specs to do attribute [Clamp] long foo; [16:27:53.0000] I'm sorry we didn't do that immediately :( [16:28:07.0000] Domenic: ok, I’m not sure there are any [16:28:37.0000] I think there might be some for [TreatNullAs], but yeah, I guess it is kind of rare in general [16:28:39.0000] Domenic: I couldn’t immediately find any use like that in real use, only our tests [16:28:46.0000] /me nods [16:28:48.0000] The more common case is [X] optional Y -> optional [X] Y [16:28:54.0000] in arguments lists [16:29:03.0000] yes, is that still allowed? [16:29:19.0000] No, optional is an annotation on the type, so it needs to become optional [X] Y [16:29:37.0000] Domenic was too fast for [16:29:47.0000] me. [16:29:56.0000] :) [16:30:54.0000] Domenic: oh i see, so step 4 of https://heycam.github.io/webidl/#idl-type-extended-attribute-associated-with, is only refereing to the non-optional variant of the argument production [16:30:57.0000] ok [16:31:33.0000] Yeah, I guess "within" is ambiguous between "directly within" and "within after expanding the grammar" [16:31:50.0000] Domenic: I was a bit confused :) [16:32:01.0000] Let me file an issue and fix over the next day or two [16:32:05.0000] Domenic: thanks [16:34:33.0000] https://github.com/heycam/webidl/issues/341 [16:35:08.0000] the other question was what step 3 of that algorithm is trying to do, does it mean that for something like [Clamp] long or DOMString) , the longs annotated type might have [Clamp]? [16:35:15.0000] or am I reading that totally wrong [16:36:04.0000] I think the intention is that [Clamp] (long or double) means that the long has a [Clamp] associated with it [16:36:16.0000] Domenic: ok, [16:36:21.0000] I hope the parens are required when defining union types... [16:36:25.0000] oh damn, I forgot a ( [16:36:36.0000] ah yes they are, phew [16:36:38.0000] Domenic: they are, I just mistyped :( [16:36:58.0000] It'd be good to add examples to each of these steps, actaully [16:37:32.0000] I am unclear how that doesn’t lead to an error case however, since the [Clamp] would get added to double as well, which is not allowed [16:37:45.0000] Oh, I forgot where clamp is allowed [16:38:13.0000] OK, integer types only, so I guess... there is no good example for clamp at least [16:38:16.0000] Domenic: just integers [16:38:29.0000] Yeah and you can't put two integers in a union I am pretty sure [16:38:36.0000] right, or two strings [16:39:13.0000] so i guess that step is pretty much dead code given the current set of extended attributes applicable to types [16:39:17.0000] I guess, maybe in the future, there will be an extended attribute useful on all types :) [16:39:21.0000] But it will be very important for [AllowShared] [16:39:31.0000] Because then [AllowShared] (ArrayBuffer or Uint8Array or ...) will work [16:39:41.0000] We will likely typedef that to SharedBufferSource [16:39:43.0000] cool beans [16:39:55.0000] thanks, this really helped clarify things [16:40:20.0000] Awesome, glad to help. I'll do my best to reflect these things back into the spec ASAP. (And also update specs to use the new syntax.) [16:54:26.0000] howdy weinig! [16:55:13.0000] hi MikeSmith! [16:55:28.0000] MikeSmith: gotta run though :) 2017-04-12 [17:09:38.0000] So I just filed this issue but I realized I can't possibly be the first person to raise this: https://github.com/whatwg/streams/issues/732 [17:10:34.0000] What is the deal with the pseudo-ECMAScript interface definitions in Streams? [17:11:55.0000] [trigger sound of can of worms opening] [17:13:11.0000] ah Domenic already responded there [17:17:00.0000] yep [18:20:32.0000] Domenic: I thought of one other question :). Why can’t ReturnTypes have extended attributes? I mean, they can, if you use a typedef, but there is no direct syntax to associate an extended attribute with an operation’s return type [18:21:57.0000] Hmm, that might just be an oversight... [18:22:03.0000] Especially with the typedef thing [18:22:18.0000] want me to file an issue? [18:22:34.0000] Yeah, that'd be great :) [18:22:37.0000] k, thanks [18:23:45.0000] Although, this might be intentional, as bz says in https://github.com/heycam/webidl/pull/286#issuecomment-275307976 " ReturnType definitely shouldn't have attributes. " I don't quite understand why though, and we should if nothing else close the typedef loophole [20:50:12.0000] Domenic: Just a heads up regarding my inactivity on console - lots of exams and school work going on as the semester comes to a close - will be resuming as more time is available [23:53:17.0000] is web.archive.org the only way to get a previous version of a spec? [00:00:45.0000] annevk: in Fetch terms does a 50x result in a “network error”? [00:01:18.0000] KiChjang: yes basically, though https://platform.html5.org/history/ has archived copies of some [00:01:37.0000] but just for the HTML spec [00:09:17.0000] MikeSmith: what is a 50x result?, is that like a 10x developer? [00:09:29.0000] MikeSmith: oh wait, it's a status code, no it doesn't [00:12:33.0000] annevk: yeah specifically meant a 504 [00:13:10.0000] if a server responds to a fetch with a 504 is there any way to get to the response? [00:13:41.0000] is CORS not relevant in that case? [00:14:00.0000] MikeSmith: CORS is relevant if we're talking about a cross-origin request [00:14:20.0000] yeah cross-origin [00:14:38.0000] MikeSmith: in that case the 504 also needs to include the relevant CORS headers [00:14:59.0000] OK so if the server sends CORS headers, can you get the status message from teh response? [00:15:44.0000] doesn’t the fetch hit the .catch()? [00:15:53.0000] MikeSmith: yes and no [00:16:18.0000]

4.6.6.18 Link type "`serviceworker`"

4.6.6.18 Link type "`serviceworker`"

4.6.6.18 Link [14:04:08.0000] type "`serviceworker`"

4.6.6.18 Link type "serviceworker"

4.6.6.18 Link type "serviceworker"

4.6.6.18 Link [14:04:08.0000] type "serviceworker"

4.6.6.18 Link type "`serviceworker`"

4.6.6.18 Link type "`serviceworker`"

4.6.6.18 Link [14:04:08.0000] type "`serviceworker`"