| 08:25 | <annevk> | andreubotella: I think I understand now |
| 08:26 | <annevk> | andreubotella: well hmm, maybe not |
| 08:30 | <annevk> | andreubotella: what happens for text/plain? |
| 08:31 | <annevk> | andreubotella: it seems to me that HTML should maybe be modified, that it flattens the File into its filename if the encoding is not multipart/form-data |
| 08:32 | <annevk> | andreubotella: and then we can modify urlencoding by asserting that value is always a string |
| 10:11 | <andreubotella> | annevk: that's right, I hadn't considered text/plain |
| 10:12 | <andreubotella> | annevk: but I'm not sure about having to depend on the enctype when constructing the entry list |
| 10:14 | <andreubotella> | s/enctype/method |
| 10:14 | <andreubotella> | it means you couldn't do this even when the enctype is UTF-8: |
| 10:14 | <andreubotella> | const formdata = new FormData(formElement); fetch("https://example.com";, {method: "POST", body: formdata}); |
| 10:17 | <andreubotella> | then again, I don't think you can currently convert from a FormData into a urlencoded or text/plain representation, so maybe that can work |
| 10:22 | <annevk> | andreubotella: constructing the <form> entry list has access to enctype, I agree it's not ideal, but it seems better than to normalize in two completely different places to me |
| 10:22 | <annevk> | andreubotella: and yeah, FormData can only be serialized as multipart/form-data and I'd prefer keeping it that way |
| 10:24 | <andreubotella> | annevk: so we'd be going the safari way in these tests, I guess: https://wpt.fyi/results/FileAPI/file/send-file-formdata-controls.tentative.html?label=experimental&label=master&aligned |
| 10:25 | <andreubotella> | https://wpt.fyi/results/html/semantics/forms/form-submission-0/newline-normalization.html?label=pr_head&max-count=1&pr=26747 too |
| 10:32 | <annevk> | andreubotella: I thought we generally wanted to follow Chrome as it is closest to the spec? |
| 10:32 | <annevk> | It's hard to go from those results to the actual tests so I'm not sure |
| 10:33 | <andreubotella> | annevk: here Chrome does everything by the spec except that it also normalizes newlines for urlencoded (haven't checked text/plain though) |
| 10:34 | <andreubotella> | hm, I might be confusing things |
| 10:34 | <annevk> | andreubotella: yeah, and urlencoded / text/plain we'd make a change in HTML for to flatten a File to a string; I think that makes the most sense to me |
| 10:39 | <andreubotella> | annevk: my bad, I was thinking that there would be some change in behavior when creating a multipart entry list, when it wouldn't be the case |
| 10:40 | <andreubotella> | so yeah, FormData wouldn't be affected at all |
| 11:16 | <jkt_> | annevk: rfc1918 should probably follow the naming convention of COR* :D |
| 11:16 | <annevk> | jkt_: that's a great suggestion for that issue |
| 11:17 | <annevk> | COIAP |
| 11:17 | <annevk> | Cross-origin IP address preflights |
| 11:17 | <jkt_> | Please don't take me seriously :D |
| 11:18 | <annevk> | don't say things you'll regret :p |
| 11:19 | <jkt_> | The joke would be on you having to explain it to browser devs :D. No CORB with a B for Boy.... etc |
| 11:22 | <jgraham> | I'm awaiting CORBLIMEY with a Dick van Dyke logo |
| 11:37 | <jkt_> | WhatWG swag right there |
| 22:37 | <saber1> | Domenic: if I read this correctly https://github.com/whatwg/html/pull/4184#issuecomment-739054218, do you mean that we should only try to move it forward after Firefox also has <dialog> shipped in release? |
| 22:37 | <Domenic> | saber1: no, I'm saying that we require multiple implementers interested to move the change forward, and although Firefox is interested, you need to recruit a second one. |
| 22:38 | <saber1> | Domenic: ah okay, sorry about that, I thought Chrome had the interests |
| 22:39 | <Domenic> | Nah, see https://github.com/whatwg/html/pull/4184#issuecomment-440326010 |
| 22:45 | <saber1> | gotcha, I misread |