| 01:23 | <MikeSmith> | the WebGL working group actually has a chair? |
| 04:50 | <jamesr___> | i would expect ever khronos working group has a chair |
| 05:09 | <MikeSmith> | jamesr___: yeah it's just that they don't have any kind of public information page for the group, so I guess nobody except that people in the group actually know who the chair is |
| 09:04 | <annevk> | zewt: it's a certificate with three name entries, *.spec.whatwg.org, *.whatwg.org, and whatwg.org |
| 10:23 | <JakeA> | annevk: https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#installation-algorithm 5.5 resolves a promise, 5.7 triggers an event. Would the event trigger before I add a listener in my promise callback? |
| 10:23 | <JakeA> | Trying to work out how promise resolving works in spec land |
| 10:25 | <annevk> | JakeA: the promise's callbacks are run during a microtask, that's guaranteed to happen before a task |
| 10:25 | <annevk> | JakeA: however, encouraging that kind of flow seems counter to the point of promises |
| 10:25 | <annevk> | JakeA: e.g. if I ask for a promise's value at a later stage, you sort of expect the same set of guarantees, but perhaps I'm wrong about this |
| 10:29 | <JakeA> | annevk: yah, it's more interop detail than usecase. Will make a ticket. |
| 10:30 | <annevk> | JakeA: Domenic and I have been thinking of language that would let the event dispatch as part of the first callback of the promise |
| 10:30 | <annevk> | JakeA: as if you had written promise.then(x => obj.dispatchEvent(...)) or some such |
| 10:30 | <annevk> | JakeA: in the algorithm |
| 10:31 | <JakeA> | annevk: interesting. Although I don't think that's what we want in this case, since it's observable from other windows |
| 10:32 | <annevk> | JakeA: ah yeah, that text is wrong |
| 10:32 | <annevk> | JakeA: you need to list the event loops on which you want to dispatch the event |
| 10:33 | <annevk> | JakeA: otherwise you queue tasks to the event loop of the service worker on objects that don't exist... |
| 10:37 | <JakeA> | annevk: so it would be "for each service worker client using registration, queue a task to fire a simple event named updatefound on all ServiceWorkerRegistration objects"? |
| 10:37 | <JakeA> | (I'm looking at https://html.spec.whatwg.org/multipage/browsers.html#downloading-or-updating-an-application-cache:event-appcache-updateready as a guide |
| 10:39 | <annevk> | JakeA: that's not specific enough |
| 10:39 | <JakeA> | annevk: is appcache's specific enough? |
| 10:39 | <annevk> | JakeA: for each ServiceWorkerRegistration object you need to figure out its corresponding event loop |
| 10:40 | <annevk> | JakeA: appcache runs in the same event loop as the document |
| 10:40 | <annevk> | JakeA: so unlikely |
| 10:41 | <annevk> | (although at some point appcache was also made available from workers, so maybe? hmm) |
| 10:42 | <JakeA> | annevk: but appcache's updateready event happens across multiple documents, so different event loops right? Or do all documents share the same event loops in spec land? |
| 10:42 | <JakeA> | "same event loop" even |
| 10:43 | <annevk> | JakeA: same-origin documents most likely do as doing anything else is likely to be observable |
| 10:43 | <annevk> | JakeA: even cross-origin documents often have to be same event loop |
| 10:44 | <annevk> | JakeA: however, it's not a given that existing text is actually accurate or vetted unfortunately |
| 10:44 | <annevk> | JakeA: since we're still figuring out much of the architecture ourselves, in order to write specs you have to understand what you're writing down |
| 10:44 | <annevk> | JakeA: and be able to verify it's correct |
| 10:45 | <annevk> | (I haven't always done that, and typically it comes back to bite me hard) |
| 10:52 | <annevk> | JakeA: it is somewhat amusing that you are using AppCache as an inspiration for the language in the specification after becoming famous for the "appcache is a douchebag" meme |
| 10:53 | <JakeA> | annevk: :D doesn't mean the spec language is bad |
| 10:53 | <JakeA> | annevk: lots of edge case we've ran into, we've dug into the spec and found "appcache woz here" scrawled in blood |
| 10:54 | <JakeA> | eg, what to do when <object> can be a navigation or subresource depending on the response |
| 10:57 | <annevk> | also <embed>, so shitty |
| 10:57 | <JakeA> | yeeep |
| 10:58 | <annevk> | I wouldn't mind that if you use service workers they become subresource-only contexts |
| 11:01 | <JakeA> | annevk: I think we went the other way & declared them all navigations (else SVG would fail, right?) |
| 11:03 | <annevk> | JakeA: I would have picked dominant usage (plugins) over SVG I think |
| 11:04 | <annevk> | JakeA: SVG can use <iframe> and <img> |
| 11:05 | <JakeA> | annevk: ohh, actually I think we bypass SW for <object> because of plugins, until we get a better idea of how to handle security there |
| 11:06 | <JakeA> | annevk: we should spec that until we have a good way to protect against it. Things like cross-domain.xml are scary, since they're per-plugin. |
| 11:08 | <annevk> | JakeA: and <embed> too? |
| 11:09 | <annevk> | JakeA: they have request contexts so you can branch on that |
| 11:09 | <slightlyoff_> | Yes, embed too |
| 11:09 | <annevk> | Did Mozilla sign off on this? |
| 11:10 | annevk | doesn't remember any discussion |
| 11:12 | <JakeA> | annevk: it was an area of "not supported" we were going to have in Chrome, but I'm thinking we should spec it until we find a way to spec it securely |
| 11:12 | <JakeA> | (not even sure how we do that without having per-plugin instructions and whitelist particular plugins) |
| 11:12 | <annevk> | Well there's an open issue on object/embed too |
| 11:13 | <JakeA> | I'll jump on that now |
| 11:13 | <JakeA> | annevk: Ok so, with the event dispatching thing, I'm thinking a Service Worker Client needs a reference to the client's incumbent settings object. Then, when it comes to dispatching updatefound, we can sort clients by identical responsible event loop, get the registration objects from the clients, dispatch events |
| 11:13 | <annevk> | Service Worker Client -> ServiceWorkerRegistration? |
| 11:14 | <JakeA> | annevk: client already has an associated registration |
| 11:14 | <JakeA> | https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#service-worker-client-concept |
| 11:15 | <annevk> | Ah yeah, I still think we should include dedicated workers there too |
| 11:16 | <annevk> | JakeA: how about we make service worker client match request's client and make it an extension of the environment settings object instead? |
| 11:16 | <annevk> | JakeA: that way a) you have access to the event loop (stored on that object) and b) we actually get some consistency |
| 11:18 | <JakeA> | annevk: yeah that makes sense, I hadn't realised client had 'forked' between the two specs |
| 11:18 | <annevk> | I don't think there's even a reason to call it "service worker client" |
| 11:19 | <annevk> | We can just define an extension to the "environment settings object" |
| 11:19 | <JakeA> | annevk: so what gets its own "environment settings object"? |
| 11:20 | <annevk> | JakeA: workers, and document/window |
| 11:21 | <JakeA> | annevk: we've had this discussion before, but I can't remember the reasons, why can't we treat dedicated workers as a subresource? |
| 11:22 | <annevk> | JakeA: CSP doesn't treat it as a subresource, from the perspective of Referer it's not a subresource |
| 11:22 | <JakeA> | annevk: yeah, that settles it really. Cool. |
| 11:24 | <JakeA> | although CSS isn't a subresource in terms of Referer either |
| 11:25 | <annevk> | JakeA: yeah, but is for CSP |
| 11:25 | <JakeA> | annevk: yeah, consistency with CSP is good |
| 11:25 | <annevk> | JakeA: CSS is a bit weird I guess; I wonder how HTML Imports handle Referer |
| 11:26 | <annevk> | Although I like how CSS handles Referer, it makes a lot of sense and has less leakage |
| 11:27 | <JakeA> | annevk: I'm sure font foundries would prefer the referrer to be the page |
| 11:27 | <slightlyoff> | CSP can change if the pun is too weak |
| 11:29 | <annevk> | I think handling this at the level of JS globals makes an awful lot of sense, irrespective of CSP |
| 11:31 | <annevk> | Otherwise effectively what you're saying is that a DedicatedWorker cannot initiate its own Fetch instance, it has to negotiate it through a Document/Window |
| 11:31 | <annevk> | That seems odd to me |
| 11:31 | <annevk> | And expensive as they're all different event loops that now have to coordinate |
| 11:52 | <slightlyoff> | That's always going to be true. Accommodating multi-process browsers demands it |
| 11:52 | <slightlyoff> | We're not going to sync tics for spec convenience |
| 11:52 | <slightlyoff> | (sorry) |
| 11:53 | <annevk> | Yes, I'm saying you're doing the opposite here |
| 11:53 | <slightlyoff> | I see |
| 12:26 | <JakeA> | annevk: can I get to a windows visibility/focus state from a request client? (client -> document -> hidden/hasFocus) |
| 12:26 | <annevk> | JakeA: if the environment settings object's global object is a Window object you can inspect that object's associated Document |
| 12:27 | <JakeA> | annevk: I guess "A responsible document" is null for workers? |
| 12:28 | <annevk> | JakeA: (theoretically such cross-process interactions of properties would require queuing a task of sorts) |
| 12:28 | <annevk> | JakeA: it's not, which is why I adviced the above |
| 12:28 | <JakeA> | annevk: yeah, our ServiceWorkerClient is a snapshot and getting these snapshots is always async |
| 12:29 | <JakeA> | annevk: so, what is the "responsible document" of an "environment settings object" of a worker? |
| 12:29 | <annevk> | JakeA: I have to go for about an hour and a half, after that I'm ready to help with this refactoring |
| 12:30 | <annevk> | JakeA: it's the first document that created the worker I think; I think we should probably drop that concept and just store the desired state directly on the settings object |
| 12:30 | <JakeA> | annevk: no worries, going through emails, but might start before you get back |
| 12:30 | <annevk> | please do start :-) |
| 12:33 | <Ms2ger> | Hrm, Fx claims mixed content on html.s.w.o |
| 12:33 | <Ms2ger> | Anyone checked what that's about? |
| 13:48 | <smaug____> | USVString is the new name for ScalarValueString ? |
| 13:49 | <OneLove> | greetings! |
| 13:49 | <OneLove> | Is there an API for determining CPU clock speed of the host from the browser? |
| 13:52 | <jgraham> | No |
| 13:52 | <jgraham> | And there likely won't be |
| 13:52 | <jgraham> | What's the use case |
| 13:52 | <jgraham> | ? |
| 13:53 | <OneLove> | developing html5 games |
| 13:53 | <OneLove> | and screen size / resolution is not a great gage of what the client is capable of |
| 13:53 | <jgraham> | Nor is clock speed |
| 13:54 | <OneLove> | youre probably right |
| 13:55 | <jgraham> | Processors can have vastly different performance at the same clock, machines can have multiple CPUs with different speeds, users can be running other tasks in the background that use up CPU time, power saving measures can affect things |
| 13:55 | <jgraham> | etc. |
| 13:55 | <OneLove> | its very true |
| 13:55 | <jgraham> | The best solution to this is probably to adaptively adjust the settings to preserve a desired framerate, or something |
| 13:55 | <OneLove> | how would you get a rough estimate of client perf? |
| 13:55 | <JakeA> | I think it would help to know the current frame rate and maximum frame rate |
| 13:55 | <jgraham> | Which isn't too easy |
| 13:56 | <JakeA> | requestAnimationFrame should provide that kind of data |
| 13:56 | <JakeA> | I don't think max frame rate (basically refresh rate) is exposed at the moment |
| 13:56 | <jgraham> | Yeah, that seems reasonable |
| 13:57 | <jgraham> | Working out actual framerate doesn't obviously need any platform changes |
| 13:58 | <JakeA> | true |
| 13:59 | <OneLove> | yes i should be able to get what i need from requestanimationframe and window.performance |
| 13:59 | <OneLove> | thanks for the input ;) |
| 14:00 | <JakeA> | OneLove: you may be interested in https://github.com/w3c/smoothness |
| 14:00 | <JakeA> | (just a proposal at the moment) |
| 14:02 | <OneLove> | thats a nice name for an api |
| 14:07 | <annevk> | smaug____: yes |
| 14:07 | <annevk> | Ms2ger: open the console and check? |
| 14:09 | <Ms2ger> | Hrm |
| 14:09 | <Ms2ger> | Now it's no longer mixed content |
| 14:09 | Ms2ger | is confused |
| 14:12 | <annevk> | Ms2ger: perhaps one of the scripts is conditionally loading something |
| 14:14 | <gsnedders> | It's pretty sad that the University of Glasgow senate feels a need to send out an email pointing out "custom writing sites" still constitute plagerism. |
| 14:24 | <JakeA> | annevk: ServiceWorkerClient is a snapshot of state, are you happy with Client working the same? |
| 14:25 | <annevk> | JakeA: there's an open issue on this |
| 14:26 | <annevk> | JakeA: I feel like we should take some steps back, there's a difference between an underlying concept (request's client) and an actual object |
| 14:26 | <annevk> | JakeA: 1) what SW describes as "service worker client" can be the same as (request's client), an environment settings object |
| 14:26 | <JakeA> | annevk: you mean, as a first pass keep ServiceWorkerClient the API, but use the concept from fetch? |
| 14:27 | <JakeA> | ok |
| 14:27 | <annevk> | JakeA: 2) ServiceWorkerClient as object, building on top of some environment settings object, seems reasonable, however, as I pointed out elsewhere the mismatch with workers means we should probably call this BrowsingContext or some such |
| 14:28 | <annevk> | JakeA: since "Worker" and "SharedWorker" are objects representing an external environment settings object already, there's no need to introduce ServiceWorkerClient for them I think |
| 14:28 | <annevk> | JakeA: now whether BrowsingContext contains snapshotted state or has a method that returns a promise that gives you its state, seems like a distinct question |
| 14:29 | <annevk> | JakeA: though if we go with snapshotted state we need to define timing of course |
| 14:31 | <JakeA> | annevk: I thought snapshotting was agreed upon |
| 14:31 | <annevk> | JakeA: there's an open issue where a Googler suggests something else |
| 14:32 | <JakeA> | annevk: https://github.com/slightlyoff/ServiceWorker/issues/500 (reading now) |
| 14:39 | <annevk> | JakeA: see also https://github.com/slightlyoff/ServiceWorker/issues/511 and https://github.com/slightlyoff/ServiceWorker/issues/512 |
| 15:26 | <Domenic> | JakeA: +1 environments = development vs. production. You seem to have edited that out though :P |
| 15:26 | <JakeA> | Domenic: I'M BEING SILENCED (nah, I moved it to https://github.com/slightlyoff/ServiceWorker/issues/512) |
| 16:21 | <annevk> | JakeA: we could probably also reuse the term Window in SW to mean "external Window" |
| 16:23 | <annevk> | JakeA: would have to check with Hixie if it's better as BrowsingContext or Window, not sure if they have a 1:1 relationship |
| 16:23 | <JakeA> | annevk: either works for me |
| 16:24 | <annevk> | JakeA: reading the HTML spec Window seems like a safer choice |
| 16:24 | <JakeA> | annevk: the only bit of incompatibility I see so far is with associating clients with SW registrations. They currently sit on service worker clients. Can we add that to the env settings object? Or should that go on the document? |
| 16:24 | <annevk> | JakeA: one browsing context can have a whole sequence of documents/windows due to history and such |
| 16:27 | <annevk> | JakeA: SWR can come from an environment settings object, yes |
| 16:27 | <JakeA> | cool |
| 16:27 | <annevk> | JakeA: you can't put it on document because then workers wouldn't have access to it |
| 16:28 | <JakeA> | of course, oops |
| 16:29 | <Domenic> | Hmm the favicons aren't showing up in Chrome or Firefox for either Streams or DOM |
| 16:29 | <Domenic> | is the problem SVG? |
| 16:29 | <annevk> | Domenic: yes |
| 16:29 | <Domenic> | :( |
| 16:29 | <annevk> | https://annevankesteren.nl/2011/02/browser-spitting |
| 16:29 | <Domenic> | should we switch to png? |
| 16:29 | annevk | anticipated that question |
| 16:29 | <Domenic> | lol |
| 17:02 | <smaug____> | which spec defines template element |
| 17:03 | <smaug____> | https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html is missing content |
| 17:03 | <smaug____> | ah, html spec |
| 17:30 | <annevk> | Hixie: http://noncombatant.org/2014/10/12/brainstorming-security-for-the-internet-of-things/ discusses the issue about CAs and local devices |
| 17:31 | <annevk> | Hixie: looks like public-webappsec⊙wo might also look into it (there's a handful of emails) |
| 17:58 | <TALNET> | Hi |
| 17:58 | <TALNET> | New to here. |
| 17:59 | <TALNET> | Interesting web technology and community. |
| 18:02 | <TabAtkins> | ...shame if anything were to HAPPEN to it |
| 18:02 | Ms2ger | gives TabAtkins some fishes to swim with |
| 18:03 | <TALNET> | :D |
| 20:13 | <Sample> | Just saw this for the first time and thought of you guys http://xkcd.com/927/ |
| 20:14 | <Sample> | I'm sure half of you already have that printed on your wall at the moment =P |
| 20:14 | <Ms2ger> | Printing? What's that? :) |
| 20:15 | <annevk> | I should reference it from https://encoding.spec.whatwg.org/ perhaps |
| 20:15 | <annevk> | Hadn't noticed it called out encodings specifically before |
| 20:15 | <gsnedders> | Ms2ger: isn't that that thing that Opera was created for? |
| 21:22 | <Domenic> | where's code search but for gecko? |
| 21:23 | <Ms2ger> | Domenic, https://mxr.mozilla.org/mozilla-central/ |
| 21:26 | <caitp> | dxr has a cool ui though |
| 21:27 | <Domenic> | i was going to say, i thought there was a fancier one |
| 21:28 | <Ms2ger> | dxr.mozilla.org? |
| 21:28 | <Domenic> | yepyep |
| 21:35 | <Ms2ger> | Weird stuff surfaces sometimes: http://lists.w3.org/Archives/Public/www-math/2014Oct/0006.html |
| 21:37 | <TabAtkins> | ...huh |
| 22:32 | <TabAtkins> | annevk: Do you alphabetize your name under V or K? |
| 22:32 | <gsnedders> | annevk: van Kesteren |
| 22:32 | <gsnedders> | bah |
| 22:33 | <gsnedders> | TabAtkins: you ignore the van if you're Dutch, but it depends on referencing style whether you follow the Dutch habit or not |
| 22:34 | <gsnedders> | TabAtkins: so it would be "Kesteren, A. van" |
| 22:34 | <TabAtkins> | kk |
| 22:35 | <gsnedders> | (even though, yes, his surname is Van Kestern, and that "V" is capitalized when his forename doesn't preceed it) |
| 22:37 | <TabAtkins> | Cool, thanks. |
| 22:37 | <TabAtkins> | (Question from one of my Twitter followers about an unrelated person with a "van Foo" name.) |
| 22:40 | <gsnedders> | TabAtkins: personally, I just want to know why the fuck I know this. |
| 22:40 | <gsnedders> | I presume at some point I've had reason to. |
| 22:41 | <TabAtkins> | Acking annevk? |
| 22:41 | <gsnedders> | I'm guessing something linguisticsy |
| 22:42 | <TabAtkins> | Maybe one of r12a's name rants. ^^_ |
| 22:42 | <TabAtkins> | s/^_/_^/ |
| 22:55 | <astearns> | ^ I'm seeing that as a cubist face showing two sides and a left ear |
| 23:18 | <Hixie> | so, weird question, but, why are promises on microtasks and not tasks? |
| 23:18 | <TabAtkins> | Makes them faster. |
| 23:22 | <Hixie> | how so? |
| 23:22 | <TabAtkins> | Less things capable of intervening between the promise setup and its resolution. ("Faster" meaning "time to completion of callbacks".) |