| 04:51 | <MikeSmith> | annevk: so the reason wattsi doesn’t report an error for <h5 id="image-map-processing-model"><span id="processing-model"></span>Processing model</h5> but does for the following: |
| 04:51 | <MikeSmith> | <h5 id="rel-alternate"><span id="link-type-alternate"></span>Link type "<dfn data-export="" |
| 04:51 | <MikeSmith> | data-dfn-for="link/rel,a/rel,area/rel" data-dfn-type="attr-value"><code |
| 04:51 | <MikeSmith> | data-x="rel-alternate">alternate</code></dfn>"</h5> |
| 04:52 | <MikeSmith> | ... is that the second case has not only that <span id="link-type-alternate"></span> but also the <dfn><code data-x="rel-alternate">… |
| 04:53 | <MikeSmith> | which ends up as two IDs in the generated output |
| 04:54 | <MikeSmith> | and in that ase, wattsi is not reporting the <span id="link-type-alternate"></span> as an error — instead it’s reporting the error when it gets to that <dfn><code data-x="rel-alternate"> |
| 04:54 | <MikeSmith> | ... |
| 04:55 | <MikeSmith> | given all that, what do you want to do in this case? |
| 04:56 | <MikeSmith> | maybe you want it so that we report the error for that <dfn><code data-x="rel-alternate"> *only* if the preceding ID-ed element — the <span id="link-type-alternate"></span> — is non-empty? |
| 04:57 | <annevk> | Yeah that sounds reasonable |
| 05:15 | <MikeSmith> | annevk: well that turns out to be relatively hard, I think |
| 05:15 | <MikeSmith> | unless there’s something I am missing |
| 05:15 | <MikeSmith> | ...because in the current code, there is nothing that’s saving any state about each node |
| 05:16 | <MikeSmith> | hmm |
| 05:16 | <MikeSmith> | well now that I say that out loud, I realize it’s obviously wrong |
| 05:17 | <MikeSmith> | ...because it is at least saving the state information “this heading already has a span or dfn that results in an ID” |
| 05:32 | <MikeSmith> | annevk: also maybe you already know that, but I think the purpose of that code is solely for the TOC, and what to select for the markup output for that heading in the TOC |
| 05:32 | <MikeSmith> | anyway, I’ll get a patch together today |
| 06:30 | <MikeSmith> | annevk: so I am back to realizing is that current code intentionally does not error for <h5 id="rel-alternate"><span id="link-type-alternate">SOME TEXT CONTENT</span>Link type "<dfn data-export="" — but does for <h5 id="rel-alternate"><span id="link-type-alternate"></span>Link type "<dfn data-export="" |
| 06:31 | <MikeSmith> | that is, if the “nested” span or dfn has text content, no error; but if it has not text content, error |
| 06:32 | <MikeSmith> | it’s not an oversight or mistake; all the relevant code there was intentionally written to handle those cases in that way |
| 06:32 | <MikeSmith> | I do not understand why |
| 06:33 | <MikeSmith> | but what I was suggesting earlier above is effectively the exact opposite of what the current code was intentionally written to do |
| 06:34 | <MikeSmith> | therefore it seems pretty odd to just completely flip it opposite |
| 06:35 | <MikeSmith> | what seems less odd is to just drop the one condition/check that’s actually causing the error to be reported |
| 06:35 | <MikeSmith> | that is, what I suggested in https://github.com/whatwg/html/pull/5855#issuecomment-679079688 |
| 06:36 | <MikeSmith> | in testing locally, doing that causes the rendered output for that heading in both the ToC and spec body to be exactly the same |
| 06:36 | <MikeSmith> | the target of the href remains the same |
| 06:36 | <MikeSmith> | too |
| 06:38 | <MikeSmith> | but the worry is that if we drop the check, there’s some other real problem case that check was (I guess) intended to catch that it won’t catch any more in the future |
| 06:39 | <MikeSmith> | and without having a regression test for that, it’s just kind of an act of faith that it’s not gonna be breaking something in the output later in some subtle/surprising/hard-to-catch way |
| 06:40 | <MikeSmith> | but in spite of that I think we should just go ahead and drop the check |
| 06:41 | <MikeSmith> | because it’s more important to unbreak the build than it is to worry about some potential problem that many not be a real problem for us in practice anyway |
| 07:05 | <annevk> | MikeSmith: that sounds reasonable; there's also some magic with headings and <dfn> which is why I didn't put the ID on the <dfn>, but we could do that too as an alternative |
| 07:06 | <annevk> | MikeSmith: note that master is not broken so it's not breaking the build really |
| 07:06 | <MikeSmith> | well true (about not breaking master) |
| 07:07 | <MikeSmith> | as far as the alternative, I leave that up to you — but for now, I went ahead and raised https://github.com/whatwg/wattsi/pull/133 for just dropping the error |
| 12:29 | <annevk> | domfarolino: hey, are you around by any chance? |
| 12:29 | <annevk> | If you're still in Tokyo I guess it's not the best time... |
| 14:33 | <MikeSmith> | in Bikeshed, is there a literal `event` definition type? |
| 14:33 | <MikeSmith> | I don’t see it listed at https://tabatkins.github.io/bikeshed/#dfn-types |
| 14:33 | <Domenic> | I feel like I've seen it used... |
| 14:34 | <MikeSmith> | yeah |
| 14:34 | <MikeSmith> | ah wait, I guess it’s covered under https://tabatkins.github.io/bikeshed/#dfn-for |
| 14:35 | <MikeSmith> | > "attribute", "constructor", "method", "const", "event", "serializer", "stringifier", and "iterator" definitions must define what interface they’re relative to. |
| 14:35 | <TabAtkins> | It's still missing from that first list |
| 14:35 | <TabAtkins> | But yeah, https://github.com/tabatkins/bikeshed/blob/master/bikeshed/config/dfnTypes.py#L20 |
| 14:36 | MikeSmith | looks |
| 14:37 | <MikeSmith> | aha! |
| 14:37 | <MikeSmith> | cool, thanks |
| 14:37 | <MikeSmith> | always trust the actual code |
| 14:55 | <annevk> | Domenic: do you know who deals with popups at Chrome? With https://github.com/whatwg/html/issues/5872 we have the opportunity to take some more special cases away or at least finally formalize how this legacy system ought to work |
| 14:56 | <annevk> | Domenic: arai already wrote a pseudo-spec and I think they'd be willing to turn that into something more concrete |
| 14:57 | <Domenic> | I'll ask around... |
| 14:58 | <annevk> | Domenic: yeah, I was expecting that it might be tricky, but I'll remain hopeful for now 😊 |
| 15:45 | <domfarolino> | annevk: hey, am around now |
| 15:45 | <domfarolino> | My location is complicated lol. Consider me in pacific time |
| 15:47 | jgraham | concludes domfarolino has a very precisely known velocity |
| 16:41 | <annevk> | domfarolino: was wondering about default referrer policy and wpt as we have some patches for that; and also the state of it as the discussion feels unresolved |
| 16:42 | <domfarolino> | annevk: I still need to review the PR. I think everyone's aligned on changing the default policy. Going further than that is I think a point of further discussion? |
| 16:42 | <domfarolino> | annevk: oh are there WPTs up to change the default? |
| 20:17 | <annevk> | domfarolino: well the discussion is in the PR; and yeah, we have some patches in Bugzilla for wpt |
| 20:19 | <domfarolino> | I think a lot of the discussion was also in the PrivacyCG thread. |
| 20:19 | <domfarolino> | annevk: Cool, if you need me to review any WPTs let me know |
| 21:59 | <hober> | Seeing this in Bikeshed: The following refs show up multiple times in their spec, in a way that Bikeshed can't distinguish between. Either create a manual link, or ask the spec maintainer to add disambiguating attributes (usually a for='' attribute to all of them) |
| 21:59 | <hober> | spec:html; type:dfn; for:/; text:browsing context |
| 22:00 | <hober> | the two definitions are apparently https://html.spec.whatwg.org/multipage/browsers.html#browsing-context and https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigation-params-browsing-context |
| 22:08 | <hober> | I imagine that latter one should have a for='' |