| 05:28 | <annevk> | bkardell: yeah a new issue for the follow-up stuff would be great |
| 05:33 | <martin> | How high is the barrier to removing redundant parse errors from the HTML spec? I'd assume this should be coordinated with another PR to remove the respective errors from html5lib-tests? |
| 06:43 | <annevk> | Domenic: so when "prepare to run script" is called the currently running task is always non-null? So it's never called from a microtask? I.e., you cannot get there through calling navigate() from a promise callback or some such? |
| 06:48 | <martin> | What's up with the Wattsi server errors for HTML PRs? |
| 06:49 | <annevk> | martin: what kind of server error? |
| 06:53 | <martin> | e.g. https://github.com/whatwg/html/pull/9797 or https://github.com/whatwg/html/pull/9809 The PR description says:
instead of linking the previews |
| 07:00 | <annevk> | dbaron: could you please stop at-mentioning folks in commit messages? Unfortunately it's rather spammy. |
| 07:01 | <annevk> | martin: ooh that's weird, Build is succeeding. Domenic can prolly take a look in a bit. |
| 07:01 | <annevk> | I wonder if we could run PR Preview through GitHub instead, saving Tobie some resources. |
| 07:15 | <martin> | (for what it's worth I just force pushed the same commit without any content changes and the preview now worked 🤷) |
| 07:17 | <annevk> | Oh okay, sometimes our hosting provider is a bit flaky. |
| 07:17 | <annevk> | Neat, https://github.com/whatwg/fetch/issues/new/choose already has an option to report a security vulnerability. |
| 07:24 | <sideshowbarker> | Neat, https://github.com/whatwg/fetch/issues/new/choose already has an option to report a security vulnerability. |
| 07:25 | <sideshowbarker> | And the mobile app still shows the choices in a different order (with the Chat choice first) |
| 07:27 | <annevk> | File an issue against the app? |
| 07:27 | <sideshowbarker> | (I use the mobile app because I can swipe to mark as done in the Notifications UI) |
| 07:27 | <annevk> | keithamus might be able to forward it internally \o/ |
| 07:28 | <keithamus> | Oh interesting. I’ll forward to the mobile team |
| 07:28 | <annevk> | If I did GitHub on mobile my work-life balance would worsen. |
| 07:28 | <sideshowbarker> | I just wish the web-app UI let me swipe. If it did then I'd not have any other use for the mobile app… |
| 07:29 | <annevk> | But also a lot of what I do is review which even on a laptop sucks due to screen width limitations |
| 07:31 | <sideshowbarker> | Yeah |
| 07:37 | <Domenic> | Domenic: so when "prepare to run script" is called the currently running task is always non-null? So it's never called from a microtask? I.e., you cannot get there through calling navigate() from a promise callback or some such? |
| 07:38 | <Domenic> | Hmm I see the problem |
| 07:39 | <Domenic> | Note that this is not navigation API specific. Every Web IDL callback call ends up in "prepare to run script" |
| 07:40 | <Domenic> | I think the spec is not very prepared for the currently running task to be null. We should probably let it be a microtask. |
| 07:41 | <Domenic> | Oh, it's not null during microtasks after all, I was just wrong yesterday: https://html.spec.whatwg.org/#perform-a-microtask-checkpoint |
| 07:41 | <Domenic> | It is null during update the rendering though |
| 07:41 | <Domenic> | Which is maybe why "long animation frames" is a helpful thing to add, even though we are already tracking long tasks? |
| 07:48 | <Noam Rosenthal> | yea the relationship between tasks and rendering in the HTML spec is science fiction atm |
| 08:16 | <annevk> | Domenic: someone was suggesting the other day that update the rendering should be a task of its own |
| 08:16 | <annevk> | Domenic: I guess that would solve this |
| 08:17 | <annevk> | Domenic: we should also assert currently running task in queue a microtask then |
| 08:17 | <Domenic> | I get kind of upset when people talk about it this way, because the spec is observably equivalent to what browsers do today, and people are just complaining that the spec doesn't match their particular browser engine code. |
| 08:18 | <Domenic> | Like we shouldn't always reflect browser code directly in specs, and I don't like calling specs fiction if they are observably equivalent but don't match specific implementation choices. |
| 08:19 | <Domenic> | But ultimately, fine, if someone else wants to refactor the rendering steps to match how Chrome or Firefox or Safari works, go for it, I guess. |
| 08:21 | <annevk> | Yeah I'm not sure it's science fiction either, but it does seem problematic that currently running task can be null. |
| 08:32 | <Noam Rosenthal> | Like we shouldn't always reflect browser code directly in specs, and I don't like calling specs fiction if they are observably equivalent but don't match specific implementation choices. |
| 08:34 | <Noam Rosenthal> | The update the rendering steps are different from implementations in two key ways: one is that it's outside a task and the other is that it's unclear where ui events are handled |
| 08:35 | <Domenic> | I mean UI events have been only moderately specified since 1994... if someone wants to fix that I'm definitely rooting for them, but not holding my breath :) |
| 08:39 | <annevk> | Yeah, we've been frustrated with them for a while. I outlined a plan for fixing them and Gary at one point was going to tackle it, but it hasn't happened. Perhaps you want to give it a go Noam? |
| 08:39 | <Noam Rosenthal> | I might have to as part of speccing long animation frames |
| 08:44 | <annevk> | I can't find the issue for this in the uievents repository |
| 08:45 | <annevk> | There should be one somewhere about defining a proper processing model |
| 08:45 | <Noam Rosenthal> | this is what I meant when I said science-fiction: UI events are tightly integrated into rendering cycle in implementation, and there is always a task, probably a "rendering task". those two things ARE web-observable (e.g. in longtasks). Wrong choice of words, but I'd happy to try to tackle it. |
| 08:47 | <annevk> | I think it's https://github.com/w3c/uievents/issues/238#issuecomment-510106422 |
| 08:48 | <annevk> | We need the abstract algorithms of "user moves mouse", "user presses key", etc. and then bind those to the event loop somehow. |
| 08:58 | <Domenic> | Hmm someone seems to have totally ignored our new issue template https://github.com/whatwg/html/issues/9812 |
| 09:18 | <martin> | Hmm someone seems to have totally ignored our new issue template https://github.com/whatwg/html/issues/9812 Well the first option is labeled "New issue" ... and the description just says:
if you stop reading there you haven't really knowingly ignored anything. The description should probably say something that this shouldn't be used for feature requests. Perhaps "New issues" should be changed to "Report problem" or something like that. |
| 10:00 | <Noam Rosenthal> | How about "Propose a new feature" and "Report an issue" in that order? |
| 10:09 | <Noam Rosenthal> | Domenic, annevk: regarding event loop spec vs implementation, according to Ryosuke (at TPAC) webkit doesn't run everything through the event loop so there might be quite a few issues there that would arise if we try to make things more observably interoperable, especially around microtasks |
| 11:20 | <annevk> | Noam Rosenthal: hmm I thought when I spoke with rniwa he said "update the rendering" was essentially its own task |
| 11:21 | <annevk> | Noam Rosenthal: scheduling might be different, but everything has to run within the context of the event loop |
| 11:22 | <Noam Rosenthal> | annevk: "not everything is hooked up to go through that execute loop. We're in the process of adopting that but it's nowhere near complete." |
| 11:23 | <Noam Rosenthal> | (quoting our chat, as a follow up to the TPAC discussion about long animation frames) |
| 11:24 | <Noam Rosenthal> | would be amazing if webkit actually had everything in an event loop and could support long animation frames/tasks etc. I was surprised to hear that this is a problem. |
| 11:24 | <annevk> | Anyway, I don't really see a problem with surfacing more interop issues, they're already out there anyway |
| 11:27 | <Noam Rosenthal> | Absolutely agree about the value of surfacing, my concern spec-wise is that if we tried to move the event-loop + ui event spec into something more rigorous we'd get webkit pushback because of this kind of issues, so I wanted to surface this with you early. |
| 11:45 | <annevk> | Noam Rosenthal: it'd be interesting to see a more concrete example of a problem I suppose |
| 11:46 | <annevk> | Noam Rosenthal: if we need some ambiguity around which events end up in the same task that doesn't seem out of the realm of options per se, but at the moment we don't even have a framework to talk about that kind of stuff |
| 11:47 | <Noam Rosenthal> | annevk: agreed. |
| 11:47 | <Noam Rosenthal> | (I don't have concrete examples myself, less familiar of this part of webkit in its current form) |
| 14:07 | <annevk> | Sigh, the HTML declarative shadow tree PR reached the unicorn level |
| 14:08 | <Jeffrey Yasskin> | We should develop these things as monkeypatch specs and only write a PR after there's consensus. ;) |
| 14:16 | <annevk> | Heh, surely there's a middle ground here somewhere. But it's hard to know upfront sometimes. |
| 15:10 | <bkardell> | TabAtkins: I can't tell if you and I are saying the same thing, close to the same thing, or totally opposite things on that heading levels start thing - would you be interested in figuring it out together and creating a reply/plan (or just new follow up issue as suggested above) that we agree on? |
| 15:15 | <annevk> | bkardell: as far as I can tell all TabAtkins is asking for recursion when determining headingstart; I think it'd be good if someone could determine the perf cost of that is indeed about the same and it doesn't create any problems when you try to optimize things |
| 15:17 | <TabAtkins> | Yes, that's correct. Given that every heading will have to search to the root anyway to determine its actual level, the only thing you're gaining from avoiding recursion is that *sometimes* you can stop earlier than the root. That's effectively nil perf benefit. |
| 15:17 | <annevk> | someoneâ„¢ |
| 15:18 | <TabAtkins> | in other words the *existence* of this feature already has some (fairly minimal) perf hit. |
| 15:18 | <annevk> | TabAtkins: well, that's only the first pass, there's also dynamic manipulation and such |
| 15:22 | <bkardell> | feels like we do this with css already, but maybe there is something real tricky there idk |
| 15:25 | <TabAtkins> | Yeah, I think that still applies. The existence of the feature imposes a (small) cost on maintaining correct heading levels on mutation for *all* pages, regardless of whether they use it. Absolute vs recursive just, at best, avoids ah extra walk to root. |
| 15:27 | <TabAtkins> | Any perf implications are *worst* for existing pages that don't use the feature at all. Recursive is the *same* cost. Absolute might let you save a tiny amount of effort in some cases, at the cost of the page structure breaking when you nest. |
| 15:30 | <annevk> | bkardell: doesn't make it free :-) |
| 15:31 | <smaug> | annevk: I'm trying to find time for the :dir review asap, but curious, is there some particular hurry with that? |
| 15:32 | <annevk> | smaug: I don't think so, happy to wait |
| 15:33 | <annevk> | smaug: I guess I was trying to move a bit faster since it's been overdue, but might as well take a bit longer and get it right |
| 15:33 | <smaug> | sure, it has taken lots of time |
| 15:33 | <smaug> | but ok,I'll review during the weekend |
| 15:33 | <annevk> | smaug: please, take your time and just say when you've done it |
| 15:36 | <bkardell> | bkardell: doesn't make it free :-) |
| 15:37 | <bkardell> | which would at least make it "seemingly affordable" :) |
| 15:51 | <bkardell> | I guess it is not exactly like anything in css so maybe that doesn't help |
| 16:04 | <sideshowbarker> | annevk: what part of Fetch specifies that the response status for file: URLs ends up being 0? |
| 16:12 | <Noam Rosenthal> | sideshowbarker: "For now, unfortunate as it is, file: URLs are left as an exercise for the reader. When in doubt, return a network error." |
| 16:12 | <annevk> | sideshowbarker: that's not defined behavior |
| 16:13 | <annevk> | We should make that more clearly "implementation-defined". |