| 02:51 | <TimothyGu> | How is the infra "ordered map" usually implemented in browsers? Just an dynamically resized array or a combination of that and a hashmap? |
| 02:51 | <TimothyGu> | or something else? |
| 04:16 | <Domenic> | TimothyGu: https://github.com/Tessil/ordered-map/blob/master/README.md is the basic technique |
| 04:19 | <Domenic> | https://docs.oracle.com/javase/7/docs/api/java/util/LinkedHashMap.html also |
| 04:25 | <TimothyGu> | Domenic: interesting, thanks |
| 11:32 | <Ms2ger> | Huh, didn't expect this: https://chromium.googlesource.com/chromium/src/+/4c9a7b51c37e742e24f36b5d47680bce3361fb96%5E%21/ |
| 11:39 | <gsnedders> | Ms2ger: what's unexpected about that? |
| 11:39 | <Ms2ger> | That my "better error message" change actually found bugs |
| 11:40 | <gsnedders> | hah |
| 12:22 | <annevk> | yhirano__: heya are you around? |
| 12:22 | <yhirano__> | hi |
| 12:24 | <annevk> | yhirano__: I saw you've been patching some stuff around MIME types recently and was wondering if we should coordinate first somehow |
| 12:24 | <annevk> | yhirano__: e.g., Chrome not preserving the case of "utf-8" in XMLHttpRequest and always replacing might actually be better |
| 12:25 | <annevk> | yhirano__: especially given that Firefox seems to do that a lot if utf-8 is found inside a double-quoted parameter value |
| 12:26 | <yhirano__> | First, I agree with your last comment at https://github.com/whatwg/mimesniff/issues/39 |
| 12:28 | <yhirano__> | Regarding case (in)sensitivity, I don't have a strong opinion, but I "fixed" the behavior recently: https://chromium-review.googlesource.com/c/chromium/src/+/773942 |
| 12:29 | <yhirano__> | You can observe the new behavior on Chrome canary. |
| 12:29 | <yhirano__> | annvevk: ^ |
| 12:30 | <annevk> | yhirano__: a couple days ago I thought I'd seen some kind of fluke, but then today I noticed that changeset in a Chromium issue |
| 12:30 | <annevk> | yhirano__: that is, in https://github.com/w3c/web-platform-tests/pull/8422#issuecomment-346847683 I thought Chrome always replaced with UTF-8 and then I looked again later and I couldn't reproduce 😃 |
| 12:32 | <annevk> | yhirano__: the other question I have is whether we want to further restrict what are valid MIME types |
| 12:32 | <annevk> | yhirano__: e.g., should the parser reject "?/?" or not |
| 12:33 | <annevk> | yhirano__: Chrome currently only enforces this in overrideMimeType, due to an "is a valid MIME type" check, but it seems to me the implementation should always use the parser and not verify if the string is valid part of the time... |
| 12:33 | <annevk> | yhirano__: e.g., a weird thing in Chrome because of that is that Chrome will accept "text/html;" in most cases, but won't accept it for overrideMimeType |
| 12:36 | <yhirano__> | annevk: The check is relatively new (https://chromium-review.googlesource.com/547918). Previously there was no check at all. |
| 12:37 | <yhirano__> | annevk: I with we will be able to define one "validity" for the web plat and use it everywhere. |
| 12:37 | <annevk> | yhirano__: yeah, so I suppose that's flexible still (though I owe you a beverage of your choosing for all the extra work whenever we next meet) |
| 12:39 | <yhirano__> | annevk: agreed, we can change the check in overrideMimetype() a bit. |
| 12:40 | <yhirano__> | annevk: s/I with/I wish/, sorry for the typo... |
| 12:41 | <annevk> | yhirano__: I guess to determine to which code points we can restrict MIME types we need to know what code points are used... |
| 12:41 | <annevk> | yhirano__: it seems that at least for type/subtype we can restrict to whatever "token" means, but I'm a little worried about parameters |
| 12:42 | <yhirano__> | annevk: for example? |
| 12:42 | <annevk> | yhirano__: "text/html;x=?" |
| 12:42 | <annevk> | yhirano__: should we reject that entirely, or accept it as text/html with no parameters, or as text/html with x=? as parameter |
| 12:43 | <annevk> | yhirano__: same for something like text/html;charset=†|
| 12:45 | <annevk> | yhirano__: my inclination would be failure for "?/?", and dropping parameters for "x/x;?=?" or "x/x;x=?;charset=utf-8" (becomes x/x;charset=utf-8 in that case) |
| 12:46 | <yhirano__> | annevk: I guess allowing non-ascii will bring case issues (Kelvin/K/k) |
| 12:46 | <annevk> | yhirano__: so the existing text/xml;charset=†overrideMimeType case would instead expect "text/xml" as MIME type |
| 12:46 | <annevk> | yhirano__: non-ASCII brings quite a few issues as MIME types are sometimes restricted to "latin1" (e.g., HTTP) |
| 12:47 | <annevk> | yhirano__: so if you allowed non-ASCII you have to be very careful at the boundaries (think Response / Request objects) |
| 12:47 | <annevk> | yhirano__: so I'd definitely want to restrict non-ASCII personally |
| 12:47 | <annevk> | (that is, ensure it doesn't end up serialized) |
| 12:50 | <yhirano__> | annevk: your inclination sounds reasonable. |
| 12:50 | <yhirano__> | annevk: sorry I have to leave office, can we chat tomorrow? |
| 12:51 | <annevk> | yhirano__: sounds good, thanks thus far! |
| 12:51 | <yhirano__> | annevk: thanks |
| 12:51 | <annevk> | yhirano__: I'll try to make some progress on new tests and an updated spec to take all this into account |
| 14:03 | <annevk> | mathiasbynens: https://github.com/annevk/webvtt/pull/10 |
| 16:44 | <wanderview> | jgraham: should I squash commits before landing reviewed WPT test case upstream? what is the standard for the repo? |
| 16:44 | <wanderview> | squashed or unsquashed? |
| 16:46 | <jgraham> | wanderview: A series of logical commits |
| 16:47 | <jgraham> | Can be one if that makes sense, or more if that's going to be easier to understand later |
| 16:47 | <wanderview> | jgraham: is a "fix review feedback" a logical commit? |
| 16:47 | <jgraham> | wanderview: No |
| 16:47 | <wanderview> | ok |
| 17:02 | <gsnedders> | wanderview: you wrote your code correct first time! nobody needs to know otherwise! |