| 01:16 | <astearns> | Did Tab submit the appropriate workstream participation agreement before submitting his PR? |
| 02:25 | <TabAtkins> | I'm a member of Google, I'm cool. ^_^ |
| 02:26 | <othermaciej_> | Google's agreement covrers him, but also technically the agreement is not mandatory until Jan 11, 2018 |
| 02:26 | <othermaciej_> | (grace period in case people need their laywers to review, etc) |
| 05:31 | <xfq> | https://whatwg.org/ipr-policy#71-copyright-license-for-whatwg-publications |
| 05:31 | <xfq> | so https://github.com/whatwg/dom/blob/master/LICENSE and friends may need updating? |
| 05:45 | <annevk> | xfq: yeah, see Bikeshed discussion earlier today |
| 05:45 | <annevk> | xfq: we’ll get everything in order over the next couple of weeks |
| 05:50 | <xfq> | annevk: you mean, the discussion in #whatwg? |
| 05:50 | <annevk> | Yeah |
| 05:51 | <xfq> | annevk: ok, thanks for the hint! |
| 09:19 | <foolip> | MikeSmith: I love https://validator.w3.org/checklink, is there a way one could run that from Travis? |
| 09:20 | <foolip> | Or perhaps just as a daily cron job, in any case automated. |
| 09:20 | <MikeSmith> | it doesn’t handle fragment IDs that are resolved by JavaScript |
| 09:20 | <MikeSmith> | on the client side |
| 09:21 | <MikeSmith> | so it reports many false positives for broken links |
| 09:33 | <foolip> | MikeSmith: ok, that's a tricky problem... |
| 09:33 | <foolip> | MikeSmith: speedy review of https://github.com/whatwg/whatwg.org/pull/128? |
| 09:34 | <foolip> | I could write a custom checker thing with node that just collects URLs and checks for 404s, but not feeling quite that ambitious today. |
| 09:58 | <MikeSmith> | foolip: reviewed and merged |
| 09:59 | <foolip> | MikeSmith: thanks! |
| 12:34 | <annevk> | Hmm, fragment IDs resolved by JS would normally be considered an error |
| 12:34 | <annevk> | We only have that as fallback in HTML for old links we expect to be updated |
| 12:35 | <annevk> | Though we also use it as a trick sometimes I suppose |
| 12:35 | <foolip> | ReSpec specs do it too |
| 12:35 | <foolip> | And I was talking about outgoing links too |
| 12:37 | <annevk> | ReSpec should just generate the final link |
| 12:38 | <annevk> | Sending readers through any kind of additional hop is bad, unless there is a very good reason I suppose |
| 12:39 | <foolip> | ReSpec generates in the browser, so... |
| 12:40 | <foolip> | Most specs at least, WebVTT had a pre-generated one, but that was ages ago |
| 12:48 | <foolip> | botie: what can you do? |
| 12:48 | <botie> | wish i knew, foolip |
| 12:48 | <foolip> | botie: help? |
| 12:52 | <foolip> | print.pdf is broken and trying to get it working locally got into other problems, so: https://github.com/whatwg/html-build/pull/134 |
| 13:13 | <annevk> | foolip: seems we can wait a little longer to get an update from the person upstream? |
| 13:13 | <annevk> | (forgot their name, sorry) |
| 13:21 | <foolip> | annevk: sure |
| 15:23 | <Domenic> | foolip: annevk: MikeSmith: seems like we could maybe run checklink on whatwg.org, if not yet on the HTML spec? |
| 16:14 | <Domenic> | If anyone has thoughts on spec algorithm style, especially async spec algorithms, point them this way. https://github.com/whatwg/infra/issues/181 . I'm going to tag JakeA based on a hunch he would have opinions. |
| 16:15 | <annevk> | Yeah, checklink should work for all WHATWG standards |
| 16:15 | <annevk> | Even HTML I’d think |
| 16:15 | <annevk> | If we have the ReSpec bug that seems bad |
| 16:16 | <Domenic> | The problem is links *to* ReSpec specs |
| 16:18 | <annevk> | Oh |
| 16:18 | <annevk> | Sigh |
| 16:18 | <annevk> | Can we filter results? |
| 16:18 | <annevk> | Build a database of bad specs |
| 16:24 | <wanderview> | annevk: aren't you supposed to be in some kind of meeting? |
| 16:25 | <annevk> | wanderview: yeah… I’m there. |
| 16:27 | <wanderview> | annevk: I'm watching via twitter |
| 16:28 | <annevk> | 👍 |
| 16:34 | <JakeA> | Domenic: I hadn't noticed this use of "asynchronously" before, but I can't figure out what the difference is between that and "in parallel", except that is has a return value. Is that the difference? |
| 16:42 | <Domenic> | JakeA: good question. I guess the idea is that "in parallel" is the technology behind async algorithms. E.g. "in parallel" is how you actually do the work, but async algorithms is a convention for writing algorithms that do such work. I dunno, that doesn't sound clearer... |
| 16:42 | <Domenic> | JakeA: so concretely, the "in parallel"ness of the #fetching-scripts algorithms is hidden behind the calls to fetch |
| 16:42 | <Domenic> | But that's like four levels deep and in other spec |
| 16:43 | <Domenic> | So we need something to say in the HTML spec and in those four levels that indicates that this algorithm won't complete synchronously. |
| 16:44 | <JakeA> | Domenic: I tend to just write algorithms to be synchronous, then go "in parallel" at the top level |
| 16:46 | <Domenic> | Right, I guess that's usually a good option, but doesn't work for fetching-scripts because we need to do multiple fetches at the same time. Maybe? |
| 16:48 | <JakeA> | Domenic: in that case I go "in parallel" to express parallelism, but have something that waits for all those threads to complete. But yeah, I don't know if that's the best. |
| 16:48 | <JakeA> | Domenic: eg steps 7 & 8 in https://wicg.github.io/background-fetch/#attempt-a-background-fetch |
| 16:50 | <JakeA> | But using "wait for" in specs always makes me unsure |
| 16:50 | <JakeA> | (btw there are lots of type & realm issues in that draft that I now understand, don't judge me) |
| 16:58 | <wanderview> | JakeA: is there something like `async function()` for specs? |
| 16:58 | <wanderview> | I guess that implies there must be an event queue, etc |
| 16:59 | <wanderview> | at least in gecko, though, we do always have an event queue for every thread |
| 17:11 | <Domenic> | JakeA: yeah I guess the problem I see is that per the letter of that spec you linked, I'd expect a server to never see multiple requests at the same time. "For each" is sequential. |
| 17:15 | <Domenic> | JakeA: oh, but the example you dropped in the issue is much clearer. |
| 17:15 | <Domenic> | Right, nevermind, I was just wrong. |
| 17:15 | <Domenic> | background fetch is fine |
| 17:16 | <Domenic> | "run the following steps in parallel" != "run the following steps in parallel and wait for them to finish before moving on the next step" |
| 17:16 | <JakeA> | Domenic: yeah, I've been wondering if that isn't so clear |
| 17:17 | <JakeA> | wanderview: maybe related, the "parallel queue" thing might help https://html.spec.whatwg.org/multipage/infrastructure.html#parallel-queue |
| 17:21 | <wanderview> | JakeA: does "parallel queue" have an `await` equivalent? |
| 17:22 | <JakeA> | wanderview: hm, not really. It's probably unrelated |
| 17:23 | <wanderview> | JakeA: but, thats kind of what we want right? the ability to write steps like an async funciton where we can await something without blocking the thread |
| 17:26 | <JakeA> | wanderview: I dunno, isn't it simpler to just go "in parallel" then be sync there? |
| 17:26 | <JakeA> | wanderview: I tried to cover this at https://github.com/whatwg/infra/issues/181#issuecomment-351117956 |
| 17:28 | <wanderview> | JakeA: I guess if "wait for X to happen" in an "in parallel" section allows other async stuff to happen in that thread, then I guess it does what I want... "wait for X to happen" is like `await` to me |
| 17:52 | <MikeSmith> | Domenic: yeah we could run the link checker on anything at least that we trust isn’t generating anchors with JavaScript |
| 17:53 | <MikeSmith> | foolip: the way botie works is like this: |
| 17:54 | <MikeSmith> | botie, inform zcorpan I left his message for you to show foolip how botie works |
| 17:54 | <botie> | will do |
| 17:55 | <MikeSmith> | then when zcorpan joins, botie will say that message |
| 17:59 | <foolip> | Oh. But I'm always connected :) |
| 18:18 | <MikeSmith> | foolip: yeah, botie is useful for others who aren’t always connected |
| 18:18 | <MikeSmith> | ah btw, when botie says that message it will mention your nick too |
| 18:19 | <MikeSmith> | so you will get some kind of notification in your IRC client when he joins |
| 18:20 | <MikeSmith> | the format of the botie messages is, “zcorpan, at [some timestamp] MikeSmith said, I left his message for you to show foolip how botie works” |
| 18:49 | <botie> | zcorpan, at 2017-12-12 17:54 UTC, MikeSmith said: I left his message for you to show foolip how botie works |
| 20:05 | <annevk> | MikeSmith: could you maybe document botie on the IRC wiki page? Or tell me enough to do it |
| 20:10 | <Domenic> | I'm surprised https://validator.w3.org/checklink doesn't have an option to just not check the fragments actually. |
| 20:12 | <foolip> | I suppose one could apply a filter to the output, if one can get it as text |
| 21:15 | <MikeSmith> | Domenic: thanks for merging the Web-storage domintro PR |
| 21:15 | <MikeSmith> | and updating the commit message |
| 21:16 | <Domenic> | MikeSmith: for sure, sorry I've been so busy lately. Hoping to get to your SSE PR today |
| 21:17 | <MikeSmith> | I’d meant to get back to both of those before now, but neither had risen up the priority stack yet |
| 21:17 | <MikeSmith> | working on the CSS checker integration has taken a lot of time |
| 21:17 | <MikeSmith> | mostly me fixing things I regressed :) |
| 21:18 | <Domenic> | :) still it'll be a neat feature for developers I think |
| 21:18 | <MikeSmith> | yeah for sure |
| 21:19 | <MikeSmith> | one side effect of some related changes I made to the CSS checker code itself recently is that I think we’ll be able to produce a standalone css-validator.jar similar to the HTML checker vnu.jar |
| 21:19 | <MikeSmith> | that can be integrated into to CI etc |
| 21:19 | <MikeSmith> | for checking .css files, not just for embedded <style> contents |
| 21:20 | <Domenic> | Oh excellent |
| 21:40 | <MikeSmith> | wonder where TabAtkins is at on making a standalone syntax highlighter |
| 21:41 | <MikeSmith> | I think I have the wattsi code ready to just plug that in as soon as it’s available |
| 21:42 | <MikeSmith> | I’m curious how fast that syntax-highlighter script will prove to be |
| 21:43 | <MikeSmith> | it needs to be called and run about 3000 times during each build... |
| 22:55 | <TabAtkins> | I'll finish it over vacation, sorry for the delay. It's 90% done. ^_^ |
| 23:00 | <jyasskin> | TabAtkins: No working over vacations. |
| 23:25 | <annevk> | Domenic: we need some kind of label for things that got merged without agreement across implementers |
| 23:25 | <annevk> | Domenic: e.g., history.index |
| 23:25 | <annevk> | Domenic: and maybe revert after some period |
| 23:25 | <Domenic> | annevk: that had agreement. It should probably get reverted though as Chrome and Safari have not shipped it as they said they would. |
| 23:26 | <annevk> | Domenic: does give credence to you insisting on explicit approval |
| 23:26 | <Domenic> | I would approve a PR that reverts it. It's on my to-do list. |
| 23:26 | <annevk> | Domenic: ah yes, you're right |