| 00:50 | <MikeSmith> | jyasskin: I did the registration process for several of the media types and found it pretty unusable |
| 00:54 | <MikeSmith> | I recall it requiring private e-mail communication to some unarchived address, and the apparently being handled/routed through a single person |
| 00:57 | <MikeSmith> | ...and when I suggested replacing that process with something having a public record, I remember getting a reply claiming that wasn’t possible for some reason |
| 02:21 | <jyasskin> | MikeSmith: I'm definitely not an expert in IETF/IANA processes, but that does sound quite plausible. I haven't seen an indication that media types are changing, but mnot is taking over HTTP headers, and that, at least, will go to a public mailing list: https://tools.ietf.org/html/draft-ietf-httpbis-semantics-04#section-4.1.1. |
| 10:29 | <MikeSmith> | jyasskin: glad to hear there’s a better plan for HTTP headers |
| 10:34 | <MikeSmith> | I went back and re-read my e-mail exchange with the media types reviewer, and my takeaway from it is that the media-types registration process is gonna remain broken by design indefinitely ー or at least until someone new eventually takes over responsibility for it and tries to bring it into the 21st century |
| 10:37 | <MikeSmith> | annevk: about <script> do you know if it’s the case that when a <script> has a src attribute, UAs ignore the type attribute and handle it as JavaScript regardless? |
| 10:41 | <annevk> | MikeSmith: I don't |
| 10:44 | <MikeSmith> | annevk: OK anyway well I should have just take time to test before I asked. A simple test shows that current browsers don’t handle it as JavaScript if the type attribute is some non-JavaScript type |
| 10:44 | <MikeSmith> | which makes sense because I assume that behavior is what the spec requires |
| 10:45 | <MikeSmith> | so now I wonder why we have the spec disallow something like <script src="https://example.org/#data"; type="application/vnd.data"></script> |
| 10:46 | <MikeSmith> | ...that is, the spec requires any non-JavaScript script content to be inline rather than being an external resourse |
| 10:50 | <annevk> | MikeSmith: does the browser fetch the data? |
| 10:59 | <MikeSmith> | annevk: ah ー I see that no, it doesn’t fetch it if the type attribute specifies a non-JavaScript type |
| 11:00 | <MikeSmith> | I wonder if it’s worth adding a note to the spec explaining that |
| 11:00 | <annevk> | I mean, it's disallowed |
| 11:01 | <annevk> | If you want external data, why not use <link>? |
| 11:01 | <MikeSmith> | yeah I know it’s disallowed, but I mean a note to make it clear why |
| 11:02 | <MikeSmith> | I can imagine developers intuitively thinking they should be able to load external data with <script> if they can do it inline with <script> |
| 11:54 | <annevk> | MikeSmith: yeah, I guess that seems fine; seems like you've encountered some folks that wonder about this 😃 |
| 15:04 | <dtapuska> | @annevk Do you think you could review https://github.com/whatwg/fetch/pull/853 ? What are your feelings of getting this merged? Right now our I2S is blocked on it getting merged. |
| 15:10 | <annevk> | dtapuska: I can take a look now |
| 15:31 | <annevk> | dtapuska: done |
| 15:38 | <annevk> | Also, thanks a lot JakeA for the help with that PR! |
| 15:46 | <annevk> | dtapuska: I haven't checked yet, but tests and impl bugs are also needed |
| 15:46 | <annevk> | dtapuska: filed https://github.com/mozilla/standards-positions/issues/144 to see what other Mozillians think about this |
| 16:29 | <dtapuska> | annevk: I've fixed your comments (I hope) and added the impl bug links.. tests are already upstreamed as tentative in wpt |
| 16:29 | <annevk> | dtapuska: thanks, another blocker on merging is that we need two impl that are interested; did you already talk with Apple or Mozilla folks? |
| 16:33 | <annevk> | dtapuska: https://whatwg.org/working-mode#changes for reference |
| 16:42 | <dtapuska> | annevk: everyone has been silent. The TAG review didn't have any comments really, no comments on our PR other than from you. Who from Mozilla can give us an answer if this is something they will pursue? |
| 16:43 | <annevk> | dtapuska: the standards-positions thing I linked above is prolly your best bet |
| 16:43 | <annevk> | dtapuska: though perhaps the networking folks have better contacts |
| 16:50 | <Domenic> | annevk: jeez this discarding windows thing is such a deep hole of sadness you've found |
| 16:51 | <dtapuska> | annevk: thanks... I've fixed the remaining comments you made. I hope that the mozilla standards position gets some activity. |
| 17:01 | <annevk> | Domenic: these latest two issues I don't mind so much, we already needed a "closed" state soonish anyway and nulling opener browsing context seems good for memory usage |
| 17:02 | <annevk> | Domenic: but yeah, more work |
| 17:02 | <annevk> | Domenic: but I've know some of this for a while, it's the "lifetime" thing I still think we do quite poorly on |
| 18:48 | <annevk> | At least, I suspect we’ll continue to unearth bugs around bc document creation and unloading |