| 00:18 | <wanderview> | JakeA: its possible we could have an initial implementation of that in nightly for the meeting |
| 00:23 | <wanderview> | I just need to review the patches in here: https://bugzilla.mozilla.org/show_bug.cgi?id=1341738 |
| 00:58 | <TabAtkins> | annevk: Just FYI, I saw your pings, but was busy all day working with fantasai, and am about to be gone for a week. I'll get back to you on or soon after the 27th. |
| 01:14 | <JakeA> | wanderview: fetch cancellation? Oh wow, that'd be ace |
| 01:15 | <wanderview> | yea |
| 01:15 | <wanderview> | baku already wrote it... I just have to find the time to review it |
| 01:16 | <wanderview> | JakeA: are you still on holiday? |
| 01:18 | <JakeA> | wanderview: half and half. I've been working this week but off next week |
| 01:19 | <wanderview> | cool |
| 01:21 | <wanderview> | JakeA: I was thinking maybe we could do a "what have we been doing in the last 6 months" segment |
| 01:21 | <wanderview> | JakeA: to give some context about what each team has been focusing on and is probably going to focusing on in near future |
| 01:30 | <JakeA> | wanderview: that's a great idea. Will ask our team to do the same |
| 05:03 | <annevk> | JakeA: there was some other issue I pointed out |
| 05:04 | <annevk> | JakeA: exposing sw mode |
| 08:33 | <jochen__> | annevk: why is createProcessingInstruction() on an HTMLDocument supported? |
| 08:34 | <annevk> | jochen__: probably because restricting it is rather meaningless? |
| 08:37 | <jochen__> | hum, according to mdn it used to be restricted to XMLDocuments |
| 08:38 | <annevk> | jochen__: I think that's true, but I think we removed the restriction because the restriction doesn't actually restrict anyone from creating one |
| 08:39 | <annevk> | jochen__: looks like it was changed six years ago: https://github.com/whatwg/dom/commit/7c03f8dff921371e36b755cbb6370eea6a0e8a37 |
| 08:40 | <annevk> | jochen__: unfortunately we didn't file bugs for all implementations back then |
| 08:41 | <jochen__> | seems to work in blink :) |
| 08:41 | <annevk> | jochen__: so just MDN that's wrong then? |
| 08:54 | <annevk> | mkwst: you never got back to me in https://github.com/w3c/web-platform-tests/pull/2356 |
| 08:55 | <mkwst> | Wow. That's an old PR. |
| 08:55 | <mkwst> | I'll take a look. |
| 09:00 | <KiChjang> | does anyone know why script tags MUST have a </script> closing tag in order to properly close it? |
| 09:01 | <KiChjang> | i hear that if you do something like <script src="..." /> in some browsers, anything that goes after it would be treated as inline JS until the next </script> tag is encountered |
| 09:02 | <KiChjang> | that doesn't sound like intended behaviour to me, or is this actually specc'd out? |
| 09:02 | <annevk> | KiChjang: /> is a thing invented by XML that HTML didn't support until it got support for inline SVG and MathML and then it only supported it there |
| 09:02 | <annevk> | KiChjang: the HTML parser is very much specified in detail |
| 09:03 | <annevk> | mkwst: I'm cleaning up web-platform-tests a bit and that includes my own forgotten stuff |
| 09:06 | <KiChjang> | annevk, ah, so the self-closing tag on script didn't follow XML semantics? |
| 09:06 | <annevk> | KiChjang: I'm not sure what that means |
| 09:07 | <KiChjang> | i'd expect that a self-closing script tag (<script src="..." />) would not treat anything after it as inline JS |
| 09:08 | <annevk> | KiChjang: again, HTML doesn't have self-closing tags, apart from the SVG and MathML islands which are very much contained |
| 09:08 | <KiChjang> | wait if that's so, then this syntax is actually invalid HTML? |
| 09:09 | <annevk> | KiChjang: yes |
| 09:09 | KiChjang | mindblown |
| 09:09 | <annevk> | KiChjang: you can use it on void elements, e.g., <img/> |
| 09:10 | <annevk> | KiChjang: but not on arbitrary elements |
| 09:10 | <annevk> | KiChjang: and we only allow it on void elements because of the XHTML craze in the 00s |
| 09:11 | <KiChjang> | did <br> became a void element just because of this? |
| 09:11 | <KiChjang> | i think i recall it not being one before |
| 09:11 | <annevk> | It was always a void element |
| 09:11 | <annevk> | What changed is that it's now valid to write <br/> |
| 09:12 | <annevk> | (It also used to have a different name from void element, just an element without end tag I think, but that doesn't matter much) |
| 09:18 | <KiChjang> | it's kinda surprising how everything i learnt lately about HTML tags are actually all wrong |
| 09:19 | <annevk> | Maybe you're reading books from the early 00s? |
| 09:19 | <KiChjang> | i do recall that back during 00s, closing tags must always be written in HTML |
| 09:19 | <KiChjang> | it's sometime in the future it became unnecessary and /> was the new syntax that everyone was going for |
| 09:20 | <annevk> | That was the XML dream that never panned out |
| 09:20 | <KiChjang> | yes, i remember reading something that says you need to specify the HTML document version before the <head> tag |
| 09:21 | <KiChjang> | and if you want XHTML, you also need to specify it and its version |
| 09:21 | <KiChjang> | looks like we've come a long way just to use HTML again |
| 09:21 | <annevk> | version? |
| 09:21 | <KiChjang> | yes, 1.0 IIRC |
| 09:21 | <annevk> | KiChjang: https://annevankesteren.nl/2007/04/html-red-pill |
| 09:22 | <KiChjang> | ah, i'm talking about during the XHTML craze |
| 09:22 | <annevk> | ah |
| 09:22 | <KiChjang> | wasn't that the case? |
| 09:23 | <annevk> | Yeah, you'd have the 1.0 or 1.1 DOCTYPE |
| 09:23 | <annevk> | And then it could be transitional or strict |
| 09:23 | <KiChjang> | lol this brings back memories |
| 09:23 | <annevk> | And all kinds of other nonsense that didn't actually have a meaningful processing model attached to it |
| 09:23 | <KiChjang> | i never figured out the difference between trasitional and strict |
| 09:23 | <annevk> | KiChjang: comes down to https://quirks.spec.whatwg.org/ mostly |
| 09:53 | <nox> | Should reparented text nodes be coalesced when parsing? |
| 09:55 | <nox> | Let me check if the test mentioned in https://github.com/servo/servo/issues/15979 passes in Firefox... |
| 12:54 | <mkwst> | Does HTML expose a concept of "active" browsing contexts? That is, I would like to say something about the tab a user is interacting with, and not the thirtieth tab on a background window the user forgot they'd opened. |
| 13:32 | <wanderview> | mkwst: I was going to say you could use the has-focus-steps... but I think they are busted atm |
| 13:35 | <mkwst> | Step 1 of https://html.spec.whatwg.org/#has-focus-steps talks about "the top-level browsing context". Which top-level browsing context? |
| 13:36 | <wanderview> | mkwst: right... it incorrectly says any top level window has focus |
| 13:36 | <wanderview> | I think JakeA wrote an issue against it |
| 13:36 | <mkwst> | wanderview: Got it. |
| 13:36 | <wanderview> | https://github.com/whatwg/html/issues/2391 |
| 13:37 | <wanderview> | of course we still have stuff depending on this algorithm |
| 13:37 | <wanderview> | in service workers clients.matchAll() is intended to be ordered such that windows most recently interacted with are first |
| 13:38 | <mkwst> | I see. I guess from a practical perspective, this seems like the right algorithm to reference, and I can just assume that annevk, et al will fix it up? :) |
| 13:39 | <wanderview> | probably |
| 13:39 | <annevk> | Hmm, if you have bandwidth apart from coming up with Q1 goals that'd be great |
| 13:40 | <mkwst> | I still have a good ~2 weeks to come up with my plans for Q1. |
| 15:58 | <annevk> | If anyone fancies reviewing Infra PRs, I put up a bunch |
| 16:10 | <annevk> | Thanks mkwst! Will reply to the rest later today most likely, gotta collect the kid and food |
| 16:10 | <mkwst> | No worries! Thanks for your work! |
| 17:18 | <Domenic> | Posted https://github.com/tabatkins/bikeshed/issues/958 (/cc zcorpan) |
| 17:19 | <Domenic> | annevk: excited to review infra PRs, I was just thinking yesterday how it needed a bit more love |
| 17:20 | <annevk> | Domenic: four PRs left |
| 17:20 | <annevk> | Domenic: I guess you're correct about label research, probably often it can be solved by using a different "function" instead as well |
| 17:21 | <Domenic> | Yeah, although that's generally an area where specs do less breaking things into functions than software does... not sure exactly why though |
| 17:26 | <annevk> | Domenic: maybe no labels indeed: http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html |
| 17:27 | <annevk> | Domenic: perhaps in part standards do that to avoid having other standards rely on what they consider internal methods |
| 17:27 | <Domenic> | Ah that's an interesting point |
| 17:27 | <annevk> | Domenic: we don't really have a good public/private API story for standards |
| 17:28 | <annevk> | Domenic: the "host" convention from JavaScript doesn't really work for us I think |
| 17:30 | <Domenic> | Agreed, and that isn't really quite solving the same problem |
| 17:31 | <Domenic> | I'm not sure what an unobtrusive convention could be |
| 17:31 | <Domenic> | I'm thinking like a little "E" box next to the <dfn> or something? I dunno. |
| 17:35 | <annevk> | Domenic: maybe we should mark public DFNs green? |
| 17:35 | <Domenic> | ooh color that might work... |
| 17:35 | <annevk> | Domenic: just like headers |
| 17:36 | <annevk> | Domenic: and we just tag them somehow, we don't base it off export, since there's often folks wanting to refer to private stuff anyway |
| 17:37 | <Domenic> | wait why wouldn't we base it off export? |
| 17:39 | <annevk> | Domenic: I'm not sure if it happens just with monkey patches, but for those you often want to refer to things that you'd not normally consider a public API |
| 17:40 | <annevk> | Domenic: the other example is CSP explaining how it interleaves with various sub-fetch algorithms such as HTTP-network fetch that shouldn't be invoked on their own |
| 17:40 | <annevk> | So yeah, that's why you sometimes want to export private entry points |
| 17:42 | <Domenic> | Hmm |
| 17:42 | <Domenic> | I'd maybe make that opt-out |
| 17:42 | <Domenic> | E.g. <dfn export notpublic> |
| 17:44 | <annevk> | Seems reasonable |
| 17:44 | <annevk> | We should probably do it through Bikeshed since you want some kind of title attribute generated as well, so it's at least somewhat accessible |