| 00:32 | <aff23> | TabAtkins: Umm, do you think I can use cross domain video data to write to canvas and use getImage to get the video's raw data? |
| 00:33 | <TabAtkins> | No, it taints the canvas and disables the functions that get data out. |
| 00:37 | <aff23> | ah okay |
| 00:38 | <aff23> | TabAtkins: so I believe we cannot do a video src = "crossdomain.url" and use it to render on a canvas, right/ |
| 00:38 | <aff23> | ? |
| 00:39 | <TabAtkins> | You can do it, you just can't pull the data out of the canvas afterwards. All you can do is display it. |
| 00:49 | <aff23> | hmm got it |
| 00:49 | <aff23> | thanks TabAtkins ! |
| 07:15 | <ondras> | so |
| 07:16 | <ondras> | are uniforms/attributes somewhat shared/shareable when using multiple webgl shader programs? |
| 11:26 | <zcorpan_> | https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/10525830/ Implement <script nomodule> is now fixed 🎉 |
| 12:15 | <nox> | Where are the repositories for https://drafts.fxtf.org? |
| 12:15 | <nox> | Never mind, found them. |
| 12:24 | <nox> | Is there anything that can be done about drafts.csswg.org being extremely slow sometimes? |
| 12:25 | <nox> | Why does that happen |
| 12:25 | <nox> | ? |
| 15:08 | <tobie> | nox: one solution would be to rely on GH pages instead (or on top). |
| 15:09 | <tobie> | nox: not sure how easy it would be to organize given the current setup. |
| 16:00 | <jugglinmike> | rbyers: something you said at today's meeting reminded me of this |
| 16:01 | <jugglinmike> | "If you’re using Word or Photoshop and it flaked out and crashed even half as much as Web pages do, you’d scream ‘this is unacceptable.’ But people expect that websites won’t work well. That needs to change." |
| 16:01 | <jugglinmike> | https://news.microsoft.com/stories/people/james-mickens.html |
| 16:02 | <rbyers> | jugglinmike: Nice, thanks. Agreed 100%. |
| 16:03 | <gsnedders> | wait, Word *doesn't* crash that much? :) |
| 16:03 | <jugglinmike> | rbyers: Are you familiar with Mickens' work? |
| 16:12 | <jgraham> | Said like someone who hs never used Word, indeed |
| 16:13 | <jgraham> | (not saying that the web couldn't be better ofc) |
| 16:13 | <rbyers> | jugglinmike: No, I'm not. |
| 16:14 | <jugglinmike> | rbyers: He has a bunch of good papers published online. Next time you find yourself with 30 minutes to kill, I recommend https://vimeo.com/95066828 |
| 16:15 | <rbyers> | FWIW, my impression is that word got miles better by relying heavily on telemetry, crash reporting etc. Something the web still lacks in many ways IMHO (trying to fix this a bit with the Reporting API: https://github.com/wicg/reporting) |
| 16:16 | <rbyers> | jugglinmike: Thanks, added to my watch list. |
| 16:19 | <jgraham> | Out of all the theories about the web I heard "too little tracking of user activity" is one of the oddest ;p |
| 16:26 | <Domenic> | "FWIW, my impression is that word got miles better by relying heavily on telemetry, crash reporting etc." this seems very accurate from what I remember reading during the 00s |
| 16:28 | <jgraham> | (but more seriously, presumably the underlying reason that office or whatever got better is because 1) someone in a position of influence decided that they ought to, and 2) because they had the resources to pull it off. For random websites the main blocker is presumably 1&2 rarely coincide. Like the web could be vastly better for most users tomorrow if sites didn't have requests to tens of different third |
| 16:28 | <jgraham> | party sites for ads, tracking, &c. and weren't multiple Mb in size. But empirically "no-one" cares about this enough to forego whatever the benefits of all those requests are) |
| 17:43 | <TabAtkins> | nox: Yesterday the server was hit by a bunch of bad-acting spiders that were ignoring robots.txt, apparentlyh. |
| 20:23 | <jeffh> | is Domenic Denicola hereabouts? |
| 20:24 | Domenic | WAVES |
| 20:24 | jeffh | was wonderin' if that was u |
| 20:24 | <jeffh> | ok, ask u questions here in public or elsewheres (ifn u have time) ? |
| 20:24 | <Domenic> | Here works! |
| 20:25 | <jeffh> | wrt https://w3c.github.io/webauthn/#getAssertion .... |
| 20:25 | <jeffh> | 1) how do we know it is doing all its work on the background thread already ? |
| 20:26 | <jeffh> | my guess: because it is called from the body of a promise, which by definition is on the/a background thread (?) |
| 20:26 | <Domenic> | jeffh: you call it from https://w3c.github.io/webappsec-credential-management/#abstract-opdef-request-a-credential step 5.8, right? |
| 20:27 | <jeffh> | ok, yes, got it. |
| 20:29 | <KiChjang> | are there any specification documents that are standardizing VR stuff? |
| 20:30 | TabAtkins | https://w3c.github.io/webvr/ |
| 20:30 | <jeffh> | 2) "It never returns actual JS objects or messes with actual JS globals. Instead it returns the necessary data to create one" -- so this implies submitting an issue on credman to receive the "necessary data" and create the JS object(s) ? Or define in webauthn a callable alg that does it that credman can invoke from the main thread? |
| 20:30 | <wanderview> | JakeA: any chance you are around? |
| 20:36 | <jeffh> | Domenic: when you say "posting a task", is that done in spec text by just saying "[=in parallel=]" ? |
| 20:41 | <Domenic> | jeffh: no, those are kind of the opposite :) |
| 20:41 | <Domenic> | "in parallel" means "go to the background thread and run this spec text in parallel with the main thread" |
| 20:41 | <Domenic> | "queue a task" is done via [=queue a task=]. I apologize if I used "post" confusingly instead of "queue" |
| 20:42 | <jeffh> | ah! |
| 20:42 | jeffh | <-- fairly literally-minded :-} |
| 20:42 | <Domenic> | Oh, wow, I didn't realize I was looking at two separate specs |
| 20:42 | <Domenic> | That explains why Ctrl+F wasn't working as expected |
| 20:43 | <Domenic> | Given the spec split I think your latter, of a callable algorithm in webauthn, makes some sense. Now it is looking very similar to my "success steps"/"failure steps" setup in https://github.com/WebAssembly/design/pull/1093. |
| 20:45 | <jeffh> | s/latter/latter idea/ ? |
| 20:45 | <Domenic> | yeah |
| 20:46 | <jeffh> | ok, thx! so I'll try to ascertain the relevant portions of https://github.com/WebAssembly/design/pull/1093 |
| 21:08 | <aff23> | Hello. How does browser determine difference between video.src = "crossdomain.url" request and xhr request for "crossdomain.url" ? |
| 21:08 | <aff23> | because one works fine and is allowed by browser while other isn't |
| 21:19 | <aff23> | TabAtkins or anyone? |
| 21:19 | <TabAtkins> | They're different APIs? |
| 21:26 | <aff23> | TabAtkins: any documentation you can point me to? |
| 21:28 | <TabAtkins> | Not sure what you're looking for. The browser is the thing that implements the APIs. It doesn't have to tell anything apart, they're just two different pieces of code. |
| 21:28 | <TabAtkins> | One gets called when you set video.src, and knows that cross-domain is okay; another gets called when you make an XHR. |
| 21:29 | <aff23> | ah got it TabAtkins . |
| 21:29 | <aff23> | one more question, if I've a static video url, does the browser download the entire video at once? |
| 21:33 | <TabAtkins> | That's up to the browser. |
| 21:34 | <aff23> | From the network tab, I can see only 1 request |
| 21:46 | <jeffh> | Domenic: this queues a task back on "the main thread": "queue a task on the networking task source to run ...." ? |
| 21:46 | <Domenic> | jeffh: yep! |
| 21:46 | <jeffh> | so "networking task source" == "main thread" ? |
| 21:47 | <Domenic> | Nah, "queue a task" is main thread. "networking task source" means "run this after any other networking-related things already queued from background threads" |
| 21:47 | <Domenic> | But e.g. with no order constraints relative to DOM manipulation or user interaction |
| 21:47 | <Domenic> | https://html.spec.whatwg.org/multipage/webappapis.html#generic-task-sources |
| 21:47 | <jeffh> | uh.... this could all be explained better in https://html.spec.whatwg.org/ |
| 21:48 | <jeffh> | the term "main thread" appears only once in passing.... |
| 21:48 | <Domenic> | Yes, fair. It's obscured by trying to be agnostic to your actual implementation strategy (e.g. green-threads or async I/O or similar) |
| 21:48 | <Domenic> | I can work on a "for other spec writers" section |
| 21:49 | <jeffh> | yeah, that'd be helpful. so, "relevant event loop" == "main thread" ? |
| 21:50 | <Domenic> | yeah |
| 21:51 | <jeffh> | ah ok, thx. |
| 21:52 | <jeffh> | so "in parallel" means instantiating a new "background" thread, and "queue a task" means on the "relevant event loop" aka "main thread"...? |
| 21:52 | <Domenic> | queue a task in theory takes an argument on which event loop to queue the task on. But it is usually obvious unless you are writing a spec that interacts with workers or something, so that is often omitted |
| 21:53 | <Domenic> | E.g. you could in theory queue a task on some worker's event loop |
| 21:53 | <jeffh> | ok thx |
| 21:53 | <jeffh> | ah |
| 22:22 | <Domenic> | Now I need a minimal example of a function that does sync work, then async work, then some sync work... |
| 22:22 | <Domenic> | Eh, I got it |
| 22:24 | <Domenic> | Maybe I don't got it |