| 09:37 | <nox> | https://w3c.github.io/webvr/spec/1.1/ is dead |
| 09:37 | <nox> | Never mind, that's just an invalid URL on MDN. |
| 10:45 | <hsivonen> | annevk: do I understand correctly that the spec text that makes the expected output null for https://github.com/w3c/web-platform-tests/blob/master/mimesniff/mime-types/resources/generated-mime-types.json#L967 is https://tools.ietf.org/html/rfc7230#section-3.2.6 ? |
| 10:45 | <annevk> | hsivonen: https://mimesniff.spec.whatwg.org/#parsing-a-mime-type |
| 10:46 | <hsivonen> | annevk: I somehow failed to reach that by following links from the constructor of Response in the Fetch spec |
| 10:46 | <annevk> | hsivonen: they're in the mimesniff folder for that reason |
| 10:46 | <hsivonen> | annevk: thanks |
| 10:46 | <hsivonen> | annevk: yes, but the test invoked Response constructor, so I started there |
| 10:47 | <annevk> | hsivonen: ah, that might not all be hooked up concretely yet I suppose |
| 10:47 | <hsivonen> | annevk: also, Response has bytes, but the "parse a MIME type" algorithm operates on Unicode |
| 10:47 | <annevk> | hsivonen: the hope is btw that browsers get a centralized MIME type module for this that's reused everywhere |
| 10:48 | <hsivonen> | If I change the error handling policy of UTF-8 to UTF-16 conversion in Gecko, the test fails |
| 10:48 | <annevk> | hsivonen: there's some Firefox bugs for this |
| 10:49 | <hsivonen> | annevk: what spec tells me how to get from bytes in Fetch to Unicode in mimesniff? |
| 10:49 | <annevk> | hsivonen: hmm yeah, "extract a MIME type" is underdefined |
| 10:49 | <annevk> | hsivonen: the expectation is that it uses https://infra.spec.whatwg.org/#isomorphic-decode |
| 10:50 | <hsivonen> | annevk: thanks. that's not what Gecko is doing |
| 10:50 | <annevk> | hsivonen: seems a little weird since header values are supposedly always "latin1" |
| 10:50 | <hsivonen> | annevk: I'm not saying that the current code is correct |
| 10:51 | <annevk> | hsivonen: but yeah, the specs are not fully okay here and I guess I should get back to cleaning up the remainder of the MIME Sniffing integration |
| 10:51 | <hsivonen> | annevk: OK. thanks |
| 10:52 | <hsivonen> | It's kinda sad that we actually have code whose test pass level depends on our present weird error handling policy for in-RAM UTF-8 to UTF-16 conversion |
| 10:52 | <hsivonen> | the policy being that if there's an error, the result of the conversion is the empty string |
| 10:53 | <hsivonen> | silently collapsing stuff to the empty string in infrastructural code seems like Bad Idea, so I'm trying to change this |
| 11:47 | <gsnedders> | FWIW: I have no plans for dinner; if anyone from IETF land wants to meet up this evening let me know |
| 11:48 | <gsnedders> | Because, like, it'd be great to see some of you. |
| 11:50 | <annevk> | gsnedders: I'm flying around that time :/ |
| 11:51 | <gsnedders> | :( |
| 12:54 | <Domenic> | How did IETF day go? |
| 12:58 | <annevk> | Domenic: the WHATWG meetup went well, we didn't really get into URLs, but everything else we're doing was roughly agreeable |
| 13:03 | <Domenic> | Cool, much discussion of fetch? |
| 13:03 | <annevk> | Domenic: a little bit about how we can make the WebSocket bits nicer |
| 13:03 | <Domenic> | Oh cool |
| 13:04 | <annevk> | Domenic: and an action item of sorts for me to figure out what a better integration with HTTP would look like |
| 13:04 | <Domenic> | Sounds hard :) |
| 13:04 | <annevk> | Yeah, HTTP folks might work on another revision of the protocol, which might enable that so it's probably worth a shot |
| 13:06 | <Domenic> | I don't suppose data: URLs or forgiving base-64 decoding came up |
| 13:06 | <Domenic> | Or MIME parsing? |
| 13:06 | <annevk> | MIME parsing came up, nobody was phased much by not having strict handling there |
| 13:07 | <annevk> | Email might have similar parsing |
| 13:07 | <annevk> | No clear action items though |
| 13:07 | <annevk> | Didn't really discuss data: URLs |
| 13:07 | <annevk> | Or base64; I think IETF mostly prefers the base64 url variant, but I'm not sure what implementations do for that |
| 13:46 | <mathiasbynens> | …in which I use #SmooshGate as an excuse to explain why We Can’t Break The Web: https://developers.google.com/web/updates/2018/03/smooshgate |
| 17:06 | <domfarolino> | Domenic: Advice on getting https://github.com/whatwg/console/issues/113#issuecomment-370198540 rolling? |
| 17:06 | <domfarolino> | I'm a little hesitant to just ping Joseph again but not sure what else to do; chrome seems ready to move forward (https://bugs.chromium.org/p/chromium/issues/detail?id=801442#c9) |
| 17:17 | <annevk> | domfarolino: does Joseph even disagree? |
| 17:17 | <annevk> | domfarolino: you could ping some other implementers to make sure everyone agrees on a way forward, but not throwing kinda seems like the way to go based on a quick read? |
| 17:21 | <domfarolino> | annevk: Yeah, I think not throwing seems to match current behavior and is easier for implementations that don't evaluate the string when the DevTools = closed. Personally I like throwing better, but looks like that might not be the best way moving forward. |
| 19:40 | <domfarolino> | Is there an easy way to get the multipage version of a link found in the full-page version of HTML? |
| 19:44 | <annevk> | domfarolino: append the fragment to /multipage/ and wait for the client-side redirect script to run |
| 19:45 | <domfarolino> | Awesome thanks! |
| 20:55 | <KiChjang> | am i correct in thinking that WebIDL and ECMAScript are both different languages, and browsers just happen to use ECMAScript to implement WebIDL interfaces? |
| 21:02 | <TabAtkins> | KiChjang: Kinda. WebIDL was originally supposed to be an independent language for describing how interfaces should be implemented, so that you could do the actual implementation in multiple different target languages. |
| 21:03 | <KiChjang> | TabAtkins: so, would i be crazy if i think that wasm would allow other languages other than JS to implement WebIDL interfaces as well? |
| 21:03 | <KiChjang> | (once wasm is mature enough that is) |
| 21:03 | <TabAtkins> | But we abandoned that pretense a while back, because it turns out Java and JS have different execution semantics (who knew!) which changes how you want to shape the interfaces between the two languages. WebIDL is now just a more-succinct way of describing JS APIs that takes a lot of the busywork away. |
| 21:04 | <TabAtkins> | Other languages implementing APIs described by WebIDL will still run into the "other languages might not offer the same constructs in the same way" problem that Java/JS had. |
| 21:17 | <KiChjang> | hmm, so in other for other languages to substitute JS as the interface layer, they'll need to not only implement the APIs necessary, but also the execution model? |
| 21:17 | KiChjang | recalls that there is a project to replace JS with ruby in the browser |
| 21:39 | <annevk> | KiChjang: wasm will impl IDL bindings |
| 23:18 | <TabAtkins> | KiChjang: At least a little bit. Like, you can't implement WebIDL's `iterable<Foo>` if your language doesn't have something closely equivalent to iterables. |