| 05:08 | <cybai> | hi there, I'd like to ask, when using keyboard "Up arrow" key and "Down arrow" key to <input type=date>, which part of spec should I refer to? I didn't find similar things in https://html.spec.whatwg.org/multipage/input.html#date-state-(type=date) |
| 05:08 | <cybai> | thanks! |
| 06:27 | <MikeSmith> | cybai: the spec intentionally doesn’t prescribe any requirements for that |
| 06:28 | <MikeSmith> | cybai: it is up to the browser to present the appropriate UI depending on the device and input method (e.g., on mobile you’re not gonna be using up/down arrow keys there anyway) |
| 06:30 | <cybai> | MikeSmith: Ah! I see! (the mobile case makes sense to me!) and thanks answering to me! btw, I asked because when I tried to use keyboard to add date on <input type=date>, I can add to 2/31 |
| 06:30 | <MikeSmith> | ah |
| 06:30 | <MikeSmith> | that is a browser bug I guess |
| 06:30 | <cybai> | I tried on Chrome and Firefox and both of them did the same trick |
| 06:31 | <cybai> | (I'm on macOS) |
| 06:31 | <cybai> | Should I file a bug for it? |
| 06:31 | <MikeSmith> | I would yeah |
| 06:31 | <cybai> | ok! thanks! |
| 06:31 | <MikeSmith> | cheers |
| 06:31 | <cybai> | :D |
| 06:36 | <cybai> | MikeSmith: hmm, sorry, please let me ask a dummy question 🙇 Should I file the issue for both bugzilla and crbug? Or it's fine to file it at whatg/html GitHub repo? Thanks |
| 06:38 | <MikeSmith> | cybai: for both Mozilla’s bugzilla and crbug for Chrome, yeah |
| 06:39 | <cybai> | MikeSmith: thanks! |
| 06:49 | <cybai> | https://bugzilla.mozilla.org/show_bug.cgi?id=1531652 |
| 06:49 | <cybai> | https://crbug.com/937192 |
| 06:49 | <cybai> | here they are :) |
| 06:54 | <MikeSmith> | cybai: thanks ー Cc’d myself on both |
| 06:54 | <cybai> | :+1: |
| 11:24 | <Ms2ger> | annevk, wanna review https://github.com/heycam/webidl/pull/668 too? :) |
| 12:24 | <annevk> | Ms2ger: it works, but it seems a little weird to me to use an ECMAScript object for an internal data structure |
| 12:25 | <annevk> | Ms2ger: it makes me worried about that leaking somehow |
| 12:25 | <annevk> | Ms2ger: but maybe this is how implementations do it as well? 😃 |
| 12:42 | <Ms2ger> | annevk, Gecko certainly, yeah |
| 12:43 | <annevk> | Ms2ger: I guess it makes sense |
| 12:44 | <Ms2ger> | annevk, a Record could probably have worked too, but that would've meant duplicating all the "define the attributes" stuff |
| 12:45 | <annevk> | Ms2ger: some things would have to be parameterized, indeed |
| 12:46 | <Ms2ger> | annevk, maybe I could add a note that the object will never escape |
| 12:47 | <annevk> | Ms2ger: I did think of that, but either way is fine |
| 13:30 | <annevk> | Domenic: if you could direct whoever contacted you about attending the "Web Components" meeting to comment on https://github.com/w3c/webcomponents/issues/786 that'd be great |
| 13:31 | <annevk> | Domenic: I'll ensure they get in and have a say, assuming nobody objects to Mozilla hosting |
| 15:58 | <SimonSapin_> | Hi annevk. Re https://github.com/servo/rust-url/issues/488, do you think the spec should change to support path only (no authority) URLs with "://" ? |
| 16:01 | <annevk> | SimonSapin: what would that mean? |
| 16:02 | <SimonSapin> | such that indexeddb://foo/bar can parse without the cannot-be-a-base flag |
| 16:02 | <SimonSapin> | and without a host name |
| 16:03 | <SimonSapin> | ("foo" is part of the path) |
| 16:03 | <annevk> | SimonSapin: but how would we decide the schemes to apply that to? |
| 16:03 | <annevk> | SimonSapin: seems rather incompatible with a generic URL parser |
| 16:03 | <SimonSapin> | yeah that’s a good point |
| 19:28 | <annevk> | Domenic: so apparently .close() queues a task to discard a bc, but .closed knows about it directly |
| 19:29 | <annevk> | Domenic: this stuff is... |
| 19:29 | <Domenic> | Was that for all BCs or just auxiliary ones |
| 19:31 | <annevk> | Domenic: top-level I suppose (you can .close() a non-aux too in certain cases) |
| 19:31 | <annevk> | Domenic: Safari does keep opener/closed sync (in that closed will be false after close(), but true once discard happens |
| 19:33 | <annevk> | Domenic: and in Firefox at least named targeting is also affected by the internal bit .closed looks at |
| 19:33 | <annevk> | what nightmare is this |
| 21:02 | <annevk> | Domenic: for tests, when you have multiple arrays that signify parameters, is there a better pattern than nested forEach? |
| 21:03 | <Domenic> | Don't think so. Maybe declaring the two arrays up-front instead of [.......].forEach() style. Also I prefer for-of to forEach myself. |
| 21:10 | <annevk> | It’s so common I’d almost abstract it somehow |
| 21:12 | <annevk> | I guess with for-of I’d have to use a variable for the array |
| 21:25 | <Domenic> | Yeah, I find that a bit clearer |
| 21:25 | <Domenic> | Like, here's the matrix of test data, then here's the test |