| 08:52 | <MikeSmith> | annevk: Python 3 changes for html-build done, I think |
| 08:53 | <MikeSmith> | well, PR’ed |
| 09:06 | <MikeSmith> | hmm, not done yet https://travis-ci.org/github/whatwg/html-build/builds/689563011#L246 |
| 09:06 | <MikeSmith> | will try fixing that now |
| 09:16 | <annevk> | MikeSmith: cool, can we do 3.8? That's what we use elsewhere for WHATWG |
| 09:16 | <MikeSmith> | yeah sure |
| 09:16 | <annevk> | MikeSmith: seems like the changes ended up being fairly minimal too for a change |
| 09:16 | <MikeSmith> | yeah, nothing big |
| 09:17 | <MikeSmith> | most of it was updating highlighter but the more-time-consuming part of that was actually not related to Python3 migration but to other changes |
| 09:32 | <MikeSmith> | ah now the wattsi build is failing under CI https://travis-ci.org/github/whatwg/html-build/builds/689576444 |
| 09:42 | <MikeSmith> | hmm no maybe not wattsi |
| 09:42 | <MikeSmith> | something else is exiting 1 but from the Travis logs, I can’t find any way to identify what is |
| 09:43 | <MikeSmith> | need some insight from Domenic |
| 13:49 | <MikeSmith> | so it has come to my attention that for the case of custom elements, there’s no way to make the HTML checker fully conforming the spec requirements about labelable elements |
| 13:50 | <MikeSmith> | https://html.spec.whatwg.org/multipage/forms.html#category-label |
| 13:51 | <MikeSmith> | specifically, the checker is not able to distinguish between custom elements that aren’t form-associated custom elements, and custom elements that are |
| 13:52 | <MikeSmith> | that’s because determining if a custom element is a form-associated custom element requires executing JavaScript and using DOM APIs to examine the document |
| 14:23 | <Domenic> | MikeSmith: agreed. This seems like a special case of the problem described in https://html.spec.whatwg.org/#conformance-classes under "Conformance checkers" |
| 14:24 | <MikeSmith> | yeah |
| 14:27 | <MikeSmith> | as far as the effects on the checker behavior, it just means the checker won’t report an error for a label[for] reference to a custom-element that’s not really form-associated |
| 14:28 | <MikeSmith> | but non-errors as a class aren’t pain points for developers |
| 14:29 | <MikeSmith> | especially vs the alternative of reporting false positives for custom elements that are actually form-associated |
| 14:31 | <Domenic> | +1 |
| 15:14 | <eeeps> | Semi-theoretical question: what happens when a GitHub user making a PR to HTML is a member of multiple Entity orgs? Anything at all? |
| 15:26 | <annevk> | eeeps: first match per https://github.com/whatwg/participate.whatwg.org/blob/master/lib/get-user-status.js#L35 |
| 15:29 | <eeeps> | annevk: Cool. So there's no need to associate particular PRs with particular entities. The more the merrier, really. |
| 16:22 | <Domenic> | annevk: can I get a LGTM on https://github.com/heycam/webidl/pull/885? |