| 05:10 | <hsivonen> | looks like the new UTF-8 requirement isn't 100% clear: https://bugzilla.mozilla.org/show_bug.cgi?id=1406742 |
| 05:37 | <MikeSmith> | hsivonen: /me looks |
| 05:39 | <MikeSmith> | hmm yeah I guess that’s the general problem of many (most) readers of the spec not knowing the difference between UA requirements and document-conformance requirements |
| 05:39 | <MikeSmith> | not sure how we could have made it more clear in the case of the UTF-8 document-conformance requirement |
| 05:40 | <MikeSmith> | I guess we could add a note to that section saying “This is not a requirement on user agents” |
| 05:41 | <MikeSmith> | but if we did, for consistency there’s a lot of other places we should also add that |
| 05:59 | <hsivonen> | MikeSmith: yeah. I guess we'll just mark browser bug report INVALID as they arise |
| 06:50 | <annevk> | MikeSmith: what does https://twitter.com/robert_kimata/status/917251436966141954 say? |
| 06:50 | <annevk> | MikeSmith: seems a lot of the require UTF-8 tweets are from folks in Japan |
| 06:59 | MikeSmith | looks |
| 07:03 | MikeSmith | had to look up 脆弱性 |
| 07:04 | <MikeSmith> | annevk: Have read it a few times but I’m really not sure what point he’s trying to make |
| 07:04 | <MikeSmith> | in the first tweet |
| 07:04 | <MikeSmith> | He’s talking about the security risk if ISO-2022-JP |
| 07:04 | <MikeSmith> | which is a known thing of cource |
| 07:04 | <MikeSmith> | *course |
| 07:05 | <MikeSmith> | but I don’t know what he means by また、UTF-16とエンコーディングアルゴリズムが区別つかないUTF-32も使うなとある |
| 07:05 | <MikeSmith> | it sounds like he’s saying that UTF-16 is no different from UTF-32 .. in some regard |
| 07:06 | <MikeSmith> | but the follow-up tweet is pretty clear |
| 07:06 | <MikeSmith> | https://twitter.com/robert_KIMATA/status/917252289563201536 |
| 07:07 | <MikeSmith> | that one basically just says, according to the W3C HTML spec, you can still use UTF-16, and it’s OK to use it |
| 07:07 | <hsivonen> | :-( |
| 07:07 | <MikeSmith> | yeah.. |
| 07:11 | <hsivonen> | Currently, decode from UTF-16BE/LE is very slow. I've been thinking about how much complexity and effort I should put into making it faster |
| 07:11 | <hsivonen> | On one hand, using UTF-16 on the wire is such a bad idea, that I want to say "none" in protest. On the other hand, it annoys me to have the asterisk that encoding_rs decodes fast except for UTF-16BE/LE |
| 07:12 | <hsivonen> | there's a matrix of 8 cases to optimize |
| 07:12 | <hsivonen> | decoding into UTF-16 vs. UTF-8 |
| 07:12 | <hsivonen> | big-endian vs. little-endian |
| 07:13 | <hsivonen> | aligned vs. unaligned |
| 07:14 | <hsivonen> | and not just "none" in protest but also in order to make better use of time |
| 07:23 | <MikeSmith> | hsivonen: to be fair as far as what the person said in that tweet, he said more like, “If you really *must* use UTF-16, then it’s OK” |
| 07:24 | <MikeSmith> | but I guess that’s commonly the reason people give for using UTF-16, that they’re forced into it somehow for reasons outside their control |
| 07:48 | <annevk> | hsivonen: don’t unless it becomes a priority somehow? |
| 07:48 | <annevk> | hsivonen: seems more worthwhile to document why UTF-16 is bad |
| 08:32 | <annevk> | JakeA: we should figure out workers/worklets, module scripts, and service workers |
| 08:33 | <annevk> | JakeA: I think the answer is that worklets are subresources, and worker module scripts need a same-origin restriction |
| 08:34 | <JakeA> | annevk: ohh, I thought worklets were a new global that could make requests, therefore they're a client? |
| 08:35 | <JakeA> | annevk: for module scripts… why same-origin? We don't have a that requirement for importScripts |
| 08:49 | <annevk> | JakeA: seems like you missed my message in that issue |
| 08:49 | <annevk> | JakeA: you cannot have a cross-origin client fetch backed by a same-origin service worker |
| 08:50 | <annevk> | JakeA: otherwise you have some limited variant of foreign fetch |
| 08:51 | <JakeA> | annevk: I'll catch up with the issues. I'm behind post-Fronteers :D |
| 08:52 | <annevk> | JakeA: and yeah, it would be better if worklets could be a client, but I think it's probably more important you can host them on CDNs and such, and ultimately it shouldn't matter much, though we should look at what it means for referrer and such I suppose |
| 08:52 | <annevk> | JakeA: ah okay, forgot that was going on |
| 09:12 | <annevk> | That streams thread on Twitter resulted in a 150 or so mentions |
| 09:12 | <annevk> | Not a single joke |
| 10:03 | <JakeA> | oh wow I didn't realise it had that many replies |
| 11:14 | <nox> | Is it me or https://w3c.github.io/media-source/#htmlmediaelement-extensions is extremely vague? |
| 11:14 | <nox> | Err, |
| 11:14 | <nox> | https://w3c.github.io/media-source/#url |
| 11:14 | <nox> | especially the part where it basically says "oh btw, you can revoke them URLs too, but the how is left as an exercice to the reader". |
| 11:16 | <annevk> | nox: yeah, should integrate with the URL Standard somehow I suspect |
| 11:16 | <annevk> | nox: I haven't really chased up all those dependencies yet, would appreciate you filing an issue |
| 11:16 | <nox> | annevk: On which spec? |
| 11:17 | <annevk> | nox: media-source as a start |
| 11:17 | <annevk> | nox: feel free to copy me |
| 11:17 | <nox> | annevk: Ok. |
| 11:46 | <nox> | annevk: https://www.w3.org/TR/FileAPI/#BlobURLStore This is per-global, right? |
| 11:47 | <nox> | Can a same-origin worker use an URL that was created from the Window global? |
| 11:47 | <annevk> | nox: ask Mek I suppose |
| 11:47 | <nox> | Mek: ^ |
| 11:47 | <annevk> | nox: that kind of stuff is not defined well enough I think |
| 11:47 | <nox> | annevk: O RLY |
| 11:47 | nox | cries. |
| 11:48 | <annevk> | nox: I don't think it's per global per se |
| 11:48 | <annevk> | nox: maybe per event loop with some same-origin restriction |
| 12:02 | <nox> | annevk: According to Firefox, yeah it's per event loop. |
| 12:03 | <nox> | Or rather, calling it from a worker sends a runnable to the main thread for the registration, so I assume it's not per-global at the very least. |
| 12:48 | <annevk> | nox: worker and main thread sharing lookup sounds bad |
| 12:48 | <annevk> | nox: if that is true hopefully it can be removed still |
| 12:53 | <wanderview> | nox: annevk: having a worker use a blob URL create in the window (and vice versa) is pretty common I thought... in particular, we support worker scripts defined as a blob URL |
| 13:19 | <nox> | This is all so vaguely defined. :( |
| 13:35 | <nox> | annevk: https://github.com/w3c/media-source/issues/200 |
| 13:49 | <annevk> | wanderview: but can you importScripts one created in a window? |
| 13:49 | <wanderview> | annevk: I believe you should be able to... my impression that is the intent |
| 13:50 | <annevk> | wanderview: so the scope of these strings is basically unbounded? |
| 13:50 | <wanderview> | annevk: limited to the origin and the life of the global that created them, right? |
| 13:50 | <wanderview> | I mean... they can be removed after the global dies |
| 13:50 | <annevk> | wanderview: I wonder if that’s cross-browser, but in any event it would be good to nail this down |
| 13:51 | <annevk> | wanderview: same-origin, yes, lifetime of the creator global, maybe? Seems a little weird if they’re cross-global otherwise |
| 13:52 | <nox> | Well, |
| 13:52 | <nox> | MediaSource doesn't help, |
| 13:52 | <nox> | because MediaSource is Exposed=Window, and the createObjectURL from that spec is Exposed=Window too. |
| 13:53 | <nox> | Who would have known Blob URLs would be so complicated |
| 14:05 | <annevk> | createObjectURL was a bad idea and we knew it from the start 😟 |
| 14:06 | <annevk> | Just didn’t have the power to stop it |
| 14:08 | <wanderview> | annevk: we need to make these APIs consume Response objects... and make Response objects transferable |
| 14:10 | <annevk> | wanderview: yeah, maybe I should make some effort toward that |
| 14:10 | <annevk> | wanderview: Response or Blob, prolly |
| 14:11 | <wanderview> | annevk: Response would be preferable since its consumable and also integrates with ReadableStream |
| 14:11 | <wanderview> | IMO |
| 14:12 | <nox> | Is an url's object ever exposed to the Web? |
| 14:13 | <annevk> | wanderview: yeah, but I think something that does not come with a MIME type can be nice too usability-wise |
| 14:13 | <wanderview> | annevk: blob have types, no? |
| 14:14 | <annevk> | nox: not directly, if that’s what you mean |
| 14:14 | <nox> | annevk: Ok. |
| 14:14 | <annevk> | wanderview: ooh right |
| 14:14 | <wanderview> | yea, I was thinking of this: https://developer.mozilla.org/en-US/docs/Web/API/Blob/type |
| 14:14 | <nox> | annevk: So technically, even if the URL parser sets the url's object to a MediaSource instance in a worker, nothing bad is supposed to happen, right? |
| 14:14 | <wanderview> | annevk: if you want data with no type, then I think thats ReadableStream |
| 14:15 | <annevk> | wanderview: anyway, I agree we should do this, starting with Response seems good, can broaden later |
| 14:16 | <annevk> | nox: if MediaSource is not exposed there that cannot happen |
| 14:19 | <nox> | annevk: How? |
| 14:20 | <nox> | Did you mean that it shouldn’t happen? |
| 14:20 | <nox> | Because the URL parser with how it’s stated currently doesn’t care that the interface is not exposed. |
| 14:21 | <annevk> | nox: it seems the structured deserialize operation would fail when that url is fetched |
| 14:22 | <annevk> | nox: but maybe it should fail sooner |
| 14:23 | <annevk> | nox: I hope Mek can make some time to clean this up |
| 14:23 | <annevk> | nox: Blob should really be a solid part of the platform by now 😟 |
| 14:25 | <nox> | annevk: I assumed it was. |
| 14:25 | <nox> | I think I should never assume such things. |
| 14:25 | <nox> | annevk: What do you mean "when that url is fetched"? |
| 14:25 | <nox> | Oh, from a video element? |
| 14:25 | <wanderview> | annevk: did workers exist when Blob was created? |
| 14:26 | <annevk> | wanderview: not sure |
| 14:29 | <nox> | annevk: OH |
| 14:29 | <nox> | annevk: I had not noticed that srcObject exists. |
| 14:29 | <nox> | I'll just disregard Blob URLs for now (I'm implementing MSE stubs in Servo). |
| 15:24 | <annevk> | nox: why only stubs? |
| 15:25 | <nox> | annevk: Because Gecko people are changing the media stack so it's usable in Servo. |
| 15:25 | <nox> | annevk: The plan is for them to decouple it from the rest of Gecko in the cleanest way possible, |
| 15:26 | <nox> | while I implement as much as the DOM stuff in Rust, |
| 15:26 | <nox> | and then we combine our forces and join the missing dots. |
| 15:26 | <annevk> | nox: rewrite the Gecko parts in Rust? |
| 15:27 | <nox> | annevk: What do you mean? Which parts? |
| 15:27 | <nox> | The whole media stack? |
| 15:27 | <nox> | That would be above my pay-check my friend. |
| 15:27 | <annevk> | nox: heh |
| 15:28 | <nox> | annevk: I had lunch with some of them, mfw I realise most people on the media stack are IC5. |
| 15:28 | <annevk> | nox: it’s interesting that Gecko is now helping Servo without obvious benefit to Gecko |
| 15:28 | <annevk> | nox: heh |
| 15:30 | <nox> | annevk: Well, we already are using the JS engine. |
| 15:31 | <gsnedders> | nox: do you support promises yet? |
| 15:31 | <nox> | Yes since last Fall IIRC. |
| 15:31 | <gsnedders> | what was it that people kept getting annoyed at WPT using, then? |
| 15:31 | <gsnedders> | arrow functions? |
| 15:31 | <annevk> | nox: JS engine was always fairly reusable no? |
| 15:32 | <annevk> | gsnedders: yeah |
| 15:34 | <nox> | annevk: Meh. :p |
| 15:34 | <nox> | Updating it takes months. |
| 15:34 | <nox> | fitzgen is working hard on improving that though. |
| 15:35 | <gsnedders> | https://lists.w3.org/Archives/Member/w3c-css-wg/2017OctDec/0025.html — wow (re: last paragraph) |
| 15:54 | <nox> | gsnedders: arrow functions, let, const… |
| 15:55 | <nox> | gsnedders: Also, Safari doesn't support some of that stuff either, IIRC. |
| 15:55 | <gsnedders> | nox: Safari has since 10 a year ago |
| 15:56 | <nox> | Arrow functions? |
| 15:56 | <gsnedders> | yeah |
| 15:57 | <nox> | http://caniuse.com/#feat=arrow-functions disagrees |
| 15:57 | <gsnedders> | nox: huh? that shows Safari 10 supporting? |
| 15:57 | <espadrine> | gsnedders’ sentence was hard to parse, but he meant “a year ago, Safari 10” |
| 15:57 | <nox> | gsnedders: OH |
| 15:58 | <nox> | Yes. |
| 15:58 | <nox> | I read "since 10 years ago". |
| 15:58 | <nox> | Hah. |
| 15:58 | <gsnedders> | :) |
| 15:58 | <gsnedders> | but yeah, Safari 10 supported all of ES6 |
| 15:59 | <gsnedders> | I think even ES 2016 is universal now? |
| 15:59 | <gsnedders> | ES 2017 is everywhere except Edge (which tbf means that isn't relevant for WPT) |
| 18:04 | <Domenic> | annevk: my thought for cross-origin module workers was that it was just fetching the script cross-origin. It still executes like a normal worker. |
| 18:05 | <Domenic> | It doesn't execute in the target origin or anything weird like that. |
| 18:48 | <annevk> | Domenic: doesn’t work with selecting a service worker for it based on the request URL |
| 18:48 | <Domenic> | How do we select a service worker for <script src="cross-origin-url">? |
| 18:48 | <wanderview> | Domenic: the controller of the owning document |
| 18:49 | <Domenic> | OK. Do that? |
| 18:50 | <wanderview> | does anyone know if chrome separates http cache based on fetch credentials mode? |
| 20:03 | <annevk> | Domenic: that does not work for clients |
| 20:04 | <annevk> | Domenic: for clients you use the request URL |
| 20:04 | <annevk> | wanderview: pretty sure they don’t |
| 20:05 | <annevk> | wanderview: there is some discussion in a Fetch issue |
| 20:06 | <jyasskin> | annevk: https://github.com/whatwg/fetch/issues/307? |
| 20:07 | <annevk> | jyasskin: yeah |
| 21:13 | <Domenic> | annevk: why does that not work for clients? |
| 21:19 | <wanderview> | annevk: are modules clients? |
| 21:19 | <wanderview> | annevk: I thought modules were subresource requests |
| 21:20 | <wanderview> | Domenic: for non-subresource requests there is no controlling client in place... so you have to do scope matching to determine if it should intercepted |
| 21:20 | <wanderview> | are we trying to support cross-origin top level module scripts in workers or something? |
| 21:43 | <Domenic> | My intent with module workers (in the spec, not implemented) was just to allow fetching the module source text from another URL, the same way <script src=> can do |
| 21:44 | <Domenic> | But apparently this doesn't work, for reasons I don't understand. |
| 23:35 | <bathos> | I’ve got a question about interactions between module loading and HTTP2 that’s had me scratching my head for a few days — is that something appropriate to ask about here? |
| 23:37 | <jyasskin> | bathos: Yes. |
| 23:39 | <bathos> | Cool. I’ve been experimenting with serving resources using HTTP2 push — assemble a dep graph in advance and follow through on requests by provisioning their known dependencies as push promises. This works great on the whole, but there’s a quirk I’ve observed that seems to be related specifically to ES module "entrypoints". |
| 23:40 | <bathos> | I asked about it on SO, so there’s a bit of detail in the question and comments there: https://stackoverflow.com/questions/46642569/http2-push-and-native-es-modules-entry-module-push-is-ignored |
| 23:40 | <bathos> | The gist though: |
| 23:41 | <bathos> | Given a request for a document which contains <script type="module" src="something">, and an http2 session which includes a push promise for "something", the "something" push is never adopted. Instead, the browser makes a fresh request for it. |
| 23:41 | <jyasskin> | Domenic: ^ |
| 23:42 | <bathos> | Dependencies imported _in_ ES are adopted. |
| 23:42 | <jyasskin> | bathos: I'm not an expert here, but your question reminds me of the with-vs-no-credentials problem in https://github.com/whatwg/fetch/issues/354. |
| 23:42 | <bathos> | And if I reference the same module in a different way in the root document, e.g. a preload <link>, it is successfully adopted. It’s peculiar to type="module" |
| 23:43 | <bathos> | oh, interesting |
| 23:43 | <jyasskin> | Apologies if I've just sent you on a wild goose chase. |
| 23:44 | <bathos> | I have been on a lot for the last two days haha! Since HTTP2 is still pretty mysterious to me, it’d been hard to rule out the possibility that I’m doing something weird there, though I’m pretty sure at this point that I’m not. |
| 23:52 | <bathos> | jyasskin you genius! |
| 23:53 | <jyasskin> | s/genius/pattern-matcher/ :) |
| 23:53 | <bathos> | crossorigin="use-credentials" in the doc actually makes the module push promise get adopted |
| 23:54 | <bathos> | I never would have thought to try "crossorigin" on a file on the same host haha |
| 23:54 | <jyasskin> | JakeA: Do you know if anyone's looking into a devtools warning when this happens? |