| 03:43 | <Domenic> | annevk: review/rubber stamp https://github.com/whatwg/html/pull/3472 ? |
| 05:34 | <annevk> | Domenic: test commit says "first batch"? |
| 05:35 | <Domenic> | annevk: yeah, I think good enough for spec merge. Most of the rest of the tests will be manual. |
| 05:35 | <annevk> | Ooh that's a big change, I'm not gonna get to that today I think :/ |
| 05:35 | <Domenic> | Fair enough, I guess we didn't get much editorial review from the other reviewers. |
| 05:35 | <Domenic> | Each commit is pretty reasonable FWIW. |
| 20:38 | <domfarolino> | TabAtkins: When should I use `<a constructor>...` over `{{...}}` (or vice-versa) when linking to something that is defined in `<pre class=anchors>` as type `constructor`? |
| 20:39 | <domfarolino> | My understanding is that that both will link to IDL types (constructor being one) |
| 20:40 | <TabAtkins> | Yeah, there's really no reason to ever use <a> when linking to any IDL type. |
| 20:42 | <domfarolino> | TabAtkins: Sorry, I was trying to finish my question but then a professor walked in ...it seems that they produce different styles though, is `{{...}}` just generally preferred though, and `<a>` is just used for style-less linking? |
| 20:43 | <TabAtkins> | {{...}} happens to wrap itself in a <code> in the output, that's the styling difference you're seeing. |
| 20:44 | <TabAtkins> | (Or maybe it just adds a class=idl-code, which the default stylesheet targets. I forget.) |
| 20:45 | <domfarolino> | TabAtkins: Ah, iirc I think it does wrap in a <code>. Ok thanks, didn't know if it is preferred to use one over the other, but I guess that's context-dependent |
| 20:45 | <TabAtkins> | <a> is just the generic, always-works-for-all-types linking syntax. If there's a shorthand, it's usually better to use it. (And if you need to specify something that the shorthand can't accommodate, like the `spec` attribute, you should use <l spec=foo>{{something}}</l>, rather than breaking it back down fully into an <a>.) |
| 20:50 | <domfarolino> | Ok that makes sense, thank you |
| 21:12 | <paul_irish> | I've recently updated the clipboardData that Chrome sets when a user copies an image. There's some inconsistency between browsers right now regarding what types (html/text/png) are copied, and also inconsistency between paste events and drop events (in dataTransfer). who knows this area and could answer a few more questions of mine? |
| 21:17 | <domfarolino> | Domenic: Can we get away with `Call`ing the %String% constructor in https://console.spec.whatwg.org/#formatter as opposed to `Construct`ing from it? |
| 21:18 | <domfarolino> | Seems like there's no good reason to call Construct over Call in that case (since newTarget is irrelevant) |
| 21:53 | <domfarolino> | annevk: Are there wpts for https://github.com/whatwg/fetch/pull/585#issuecomment-329121865 ? |
| 23:07 | <Domenic> | domfarolino: definitely Call; Construct would incorrectly create a wrapper. |
| 23:11 | <domfarolino> | Domenic: Ok, could you possibly explain how this wrapper gets created? I'm just curious, reading https://tc39.github.io/ecma262/#sec-ecmascript-function-objects-construct-argumentslist-newtarget |
| 23:15 | <Domenic> | domfarolino: Construct sets NewTarget. From there, check the definition of the String constructor. |
| 23:15 | <domfarolino> | Domenic: Ah, I'm assuming it is because PrepareForOrdinaryCall uses newTarget instead of undefined, in [[Construct]] |
| 23:16 | <domfarolino> | Ok I'll check that out |
| 23:17 | <domfarolino> | Oh ok, thanks |