| 14:53 | <Iarfen> | hi! |
| 15:25 | <bradleymeck> | https://fetch.spec.whatwg.org/#data-url-processor looks like it makes MIME parameters with `,` in them split the MIME and the body of the data URL? e.g. data:fizz/buzz;lang="foo,bar",hi => {mime: {type: 'fizz', subtype: 'buzz', params: {lang: 'foo'}}, body: 'bar",hi' } . it seems there is some browser disagreement here though |
| 15:28 | <bradleymeck> | maybe not, just confusing |
| 15:37 | <jgraham> | mkwst: You don't happen to know why https://searchfox.org/mozilla-central/source/testing/web-platform/tests/common/security-features/resources/common.sub.js#1237-1238 is using document.write do you (it's used in upgrade-insecure-requests tests)? It seems like we never get a load event in Firefox in that case |
| 15:51 | <jgraham> | Hmm, changing that seems like maybe it changes some results :/ |
| 15:53 | <jgraham> | Oh no actually they're failing with the original setup too |
| 16:36 | <PiersW> | HTMLTableElement.tFoot says "If the new value is neither null nor a tfoot element, then a "HierarchyRequestError" DOMException must be thrown instead." and has said that since at least the DOM2 spec. But Safari, FF and Chrome all throw a TypeError, and the wpts check for that. |
| 16:36 | <PiersW> | https://html.spec.whatwg.org/multipage/tables.html#the-table-element |
| 16:37 | <PiersW> | I guess the browsers do the right thing and the spec's incorrect? |
| 16:39 | <PiersW> | Or I've misunderstood, of course. I'm just doing: document.getElementById("mytableelement").tFoot = mytableelement; (or a div element, or whatever) |
| 16:56 | <PiersW> | Ah, browsers seem to throw a type error if it's not an HTMLTableSectionElement, and a HierarchyRequestError if it's not a tfoot. |
| 16:59 | <PiersW> | That's probably what the IDL spec says, then. Ignore all this :-) |
| 17:15 | <annevk> | PiersW: it is, though it seems we could enforce all requirements in IDL if we wanted to and simplify a bit |
| 17:17 | <annevk> | Aah I see, they do not have their own class |
| 17:36 | <annevk> | Domenic: the amount of browsing context “tree” traversal that happens per event loop loop is kinda ridiculous |
| 17:36 | <annevk> | Hopefully nobody implements it as such |
| 19:52 | <Domenic> | annevk: I'm thinking harder about this and I think it's important to remember browsing context tree traversal is fine in some circumstances. Namely, when you're not taking a reference to ancestors/descendants, and just traversing once, it's well-defined. |
| 19:57 | <Domenic> | bradleymeck: I think that's worth filing an issue on Fetch for to investigate. Might keep as-is, or might want to do special handling for quoted strings. |
| 19:57 | <bradleymeck> | i couldn't find any actual examples of MIME params with commas |
| 19:59 | <Domenic> | Yeah, but I think they are theoretically allowed |
| 19:59 | <annevk> | Domenic: I don’t think that’s what we’re looking at here though. This looked like a lot of duplication and also lots of active document grabbing |
| 20:00 | <Domenic> | annevk: it seems to work OK to me, although perhaps it could be simpler. It grabs a list of documents once and then does some filtering on it. |
| 20:01 | <annevk> | Once? It does so many times in the course of a loop |
| 20:01 | <annevk> | Oh well, some other time |
| 20:07 | <bradleymeck> | Domenic made an issue, though I won't be looking into it personally anytime soon https://github.com/whatwg/fetch/issues/970 |
| 20:37 | <PiersW> | annevk: Yeah, the lack of their own class was why I got confused. It's all clear now - I was just being thick. |
| 20:53 | <bradleymeck> | Domenic: i guess it somewhat matters for serializing any JS MIME API now that I think about it as `data:${mime},${body}` wouldn't work if someone set a param value with a `,` |