| 00:14 | <domfarolino> | Domenic: Ah yes, agreed. Not sure what the best way to handle that would be unless the default was to censor ALL scripts from a module graph. Might be a bit much though |
| 00:15 | <domfarolino> | Why does c.whatwg.org redirect to the HTML spec? Just curious |
| 00:27 | <Domenic> | hysterial raisins |
| 00:27 | <Domenic> | (historical reasons) |
| 00:27 | <Domenic> | I'm not sure what they were, exactly... |
| 00:40 | <domfarolino> | 👍 |
| 00:52 | <gsnedders> | Domenic: there were redirects to all specs at whatwg.org/[xxx] added at [xxx].whatwg.org, and there were a bunch of short URLs for specific versions of HTML |
| 00:52 | <gsnedders> | IIRC |
| 05:32 | <annevk> | Only HTML ever got subdomain redirects |
| 11:06 | <MikeSmith> | https://lists.mozilla.org/pipermail/dev-platform/2018-January/021028.html 🎉 |
| 11:07 | <MikeSmith> | > JS module scripts (<script type="module">) have been enabled in nightly builds. |
| 11:10 | <ondras> | nice! |
| 13:57 | <tobie> | Can anyone enlighten me on what the purpose of the first paragraph of https://heycam.github.io/webidl/#es-operations is? |
| 14:01 | <annevk> | Domenic: whatbot looking good |
| 14:06 | <tobie> | TimothyGu: re: https://github.com/heycam/webidl/pull/494#discussion_r160318258, does that mean that the way operations are defined on namespaces is also slightly incorrect (https://heycam.github.io/webidl/#namespace-object) ? |
| 17:37 | <annevk> | tobie: that first paragraph makes sense until "unless" |
| 17:37 | <annevk> | (to me) |
| 17:38 | <annevk> | tobie: there must at least be a typo of sorts there |
| 17:39 | <tobie> | annevk: heh, yeah, I could have been more precise. |
| 17:39 | <tobie> | annevk: that's precisely the part I wanted help understanding. |
| 17:40 | <tobie> | annevk: but you knew that already. :D |
| 17:41 | <annevk> | tobie: in particular the double "and" makes that hard to parse |
| 17:42 | <tobie> | annevk: beyond the specifics, I don't understand what it's trying to do |
| 17:43 | <tobie> | Like what's the purpose of this? What is it trying to guard against. |
| 17:43 | <annevk> | tobie: I guess file an issue, ping heycam? |
| 17:43 | <annevk> | Domenic: thoughts on "topic: document lifecycle" label? |
| 17:43 | <tobie> | will do |
| 17:44 | <Domenic> | annevk: if you have lots of issues to tag with it, seems reasonable. |
| 17:44 | <annevk> | Domenic: has lots of overlap with navigation issues, but it's a big problem |
| 17:44 | <annevk> | Domenic: I often end up tagging them with navigation today |
| 19:11 | <domfarolino> | Domenic: BS spec says common conjugations are supported by default when linking to dfns, so is `lt=...` *only* necessary when you're using something that doesn't autolink, or is it just always recommended |
| 19:12 | <domfarolino> | context: `<a>navigating</a>` autolinks to HTML navigate algorithm, is `lt=navigate` just to make it future-proof in case `navigating` where to be later defined? |
| 19:13 | <tobie> | domfarolino: it depends what you want exposed in the exported terms index, really. |
| 19:14 | <tobie> | domfarolino: (at least, that's how I reason about it) |
| 19:22 | <domfarolino> | tobie: Hm i'm not sure I understand. Is there a reason to use <a lt=navigate>navigating</a> over <a>navigating</a> if they both link correctly? Just a preference? |
| 19:22 | <tobie> | domfarolino: oh, I assumed you meant in the DFN itself. Apologies. |
| 19:23 | <tobie> | domfarolino: no reason that I know of otherwise. |
| 19:25 | <domfarolino> | tobie: Ok I was wondering if that' |
| 19:25 | <domfarolino> | that's what you thoght I meant. My bad! Ok that's what I assumed, though I do like the lt just for clarity I think. Thanks! |
| 19:43 | <Domenic> | domfarolino: <a>navigating</a> seems nicer to me |
| 19:48 | <domfarolino> | Domenic: ok I saw in your review on my fetch PR you included ‘lt’ and I was wondering if it was necessary since linked correctly for me w/o |
| 19:49 | <Domenic> | Ah OK, I goofed I guess |
| 19:52 | <Domenic> | Nice https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwhatwg.org%2F |
| 20:29 | <annevk> | Encoding defines encoding and encode |
| 20:30 | <annevk> | That is the main case I know about that complicates this general rule |
| 20:31 | <domfarolino> | No worries I just wanted to make sure I understood :) |
| 22:06 | <domfarolino> | Domenic: I'll get on writing tests for that latest Console PR. Will open some browser bugs too (hm, wondering if this should have been done earlier) |
| 22:16 | <TabAtkins> | @domfarolino Bikeshed will conjugate to and from the base form, but it does *not* do "two-step" conjugations - if your dfn is "fooed", it won't autolink "fooing" to it. But if you do `<dfn lt=foo>fooed</dfn>`, then `<a>fooing</a>` will work just fine. |
| 22:17 | <TabAtkins> | The only reason to conjugate yourself in an <a> is if the conjugated work is not the last term in the definition - like if you have `<dfn>foo a bar</dfn>`, `<a>fooing a bar</a>` does *not* automatically work. You have to do `<a lt="foo a bar">fooing a bar</a>` (or with the shorthand, `[=foo a bar|fooing a bar=]`). |
| 22:22 | <TabAtkins> | (Or, of course, manually provide some conjugations in the `<dfn lt>` for convenience.) |
| 23:40 | <Mek> | hmm, what guarantees does "in parallel" in specs really give... i.e. if two different algorithms are run, one after the other, and both do some work "in parallel" at some point, is anything guaranteed with the ordering between the two in parallel blocks? |
| 23:41 | <Mek> | I guess the answer is no, and parallel queue's were invented to do give some ordering guarantees |
| 23:43 | <TabAtkins> | @Mek: Correct. Absolutely no ordering guarantees (which is the point), and ordering queues to recover that when necessary. |
| 23:47 | <Mek> | fun... although I suspect that wasn't always what people had in mind when writing specs... i.e. methods that are defined to "return a new primse and run the following steps in parallel", where that would mean that it is completely undefined what order multiple consecutive calls of that method are processed in... |
| 23:49 | <Mek> | (of course it is bad code to call the same method twice without waiting for the promise returned by the first to resolve...) |
| 23:49 | <TabAtkins> | Not necessarily? |