| 07:46 | <annevk> | devsrealmguy: that step is allocating a new Text node, so for that it needs to specify the node document |
| 10:28 | <devsrealmguy> | Thanks, that's what I was doing, I was confused when that passage says it should be the adjusted location document, after back and forth, I realized it was for emphasis. Thanks, appreciate your reply. |
| 11:49 | <annevk> | Noam Rosenthal: I think you're correct that the callback order will have to end up switching |
| 11:50 | <annevk> | Noam Rosenthal: doing anything else seems rather involved |
| 11:50 | <annevk> | It does seem like the current patch still has logic bugs |
| 11:50 | <Noam Rosenthal> | Noam Rosenthal: doing anything else seems rather involved |
| 11:51 | <Noam Rosenthal> | if there is a future use case that needs both endOfBody and done we can deal with it then |
| 11:51 | <annevk> | I don't think they have to be exclusive per se, but the consume operation will necessarily complete after EOF has been reached |
| 11:51 | <Noam Rosenthal> | yea |
| 11:51 | <Noam Rosenthal> | and request's "done" would mean "EOF" rather than something to do with whether it has been consumed |
| 11:52 | <Noam Rosenthal> | (that flag is anyway a bit strange, is it in use?) |
| 11:53 | <annevk> | It's for fetch groups, but those haven't been completely defined |
| 11:59 | <Noam Rosenthal> | annevk: ok, I re-switched the order. Did it have other logic errors? |
| 12:01 | <annevk> | I wasn't really ready evaluating this thing yet |
| 12:04 | <annevk> | Noam Rosenthal: I think this works, but we need better names, maybe in a follow-up PR |
| 12:04 | <Noam Rosenthal> | better names for "process response done" and "process response end of body"? |
| 12:04 | <annevk> | Noam Rosenthal: what's now "done" really seems more like EOF and what's now EOF really seems more like "consume body" |
| 12:05 | <Noam Rosenthal> | got it |
| 12:05 | <annevk> | I'm not sure how disruptive that will be though at this point, thoughts? |
| 12:05 | <Noam Rosenthal> | process response done is used by 2-3 places I know well |
| 12:05 | <Noam Rosenthal> | (I added all of them) |
| 12:05 | <annevk> | If I do the rename for Fetch and XHR, can you tackle the other places? |
| 12:05 | <Noam Rosenthal> | absolutely |
| 12:05 | <Noam Rosenthal> | I think I added processResponseEndOfBody to CSS, and HTML mainly uses processResponse |
| 12:06 | <annevk> | Noam Rosenthal: what's the status of https://github.com/web-platform-tests/wpt/issues/30968? Presumably some of those tests have to be updated now it's HTTP(S)-only? |
| 12:06 | <Noam Rosenthal> | Maybe processResponseEndOfStream. Also it's not exactly "process", it's more of a notification |
| 12:07 | <Noam Rosenthal> | Noam Rosenthal: what's the status of https://github.com/web-platform-tests/wpt/issues/30968? Presumably some of those tests have to be updated now it's HTTP(S)-only? |
| 12:07 | <Noam Rosenthal> | also the tests for abort are gone |
| 12:07 | <Noam Rosenthal> | it's only tests that can't be distinguished from CORS errors - like timeout, too many redirects, host not found etc. |
| 12:08 | <Noam Rosenthal> | How about "processResponseFlush"? To correspond with stream naming |
| 12:11 | <annevk> | Noam Rosenthal: yeah that also seems reasonable |
| 12:12 | <Noam Rosenthal> | request's "done" flag can be renamed to "flushed" |
| 12:13 | <annevk> | Yeah maybe. I'll merge the PR and then write the renaming patch. I think I'll just do the algorithms for now. |
| 12:13 | <Noam Rosenthal> | Yeah maybe. I'll merge the PR and then write the renaming patch. I think I'll just do the algorithms for now. |
| 12:17 | <annevk> | Noam Rosenthal: will you file impl bugs and link them from OP? |
| 12:18 | <Noam Rosenthal> | Noam Rosenthal: will you file impl bugs and link them from OP? |
| 12:20 | <annevk> | Noam Rosenthal: does "Create timing info for HTTP(S) network errors" seem like an accurate commit message to you? |
| 12:20 | <Noam Rosenthal> | Noam Rosenthal: does "Create timing info for HTTP(S) network errors" seem like an accurate commit message to you? |
| 12:40 | <annevk> | Noam Rosenthal: https://github.com/whatwg/fetch/pull/1369 |
| 12:41 | <Noam Rosenthal> | Noam Rosenthal: https://github.com/whatwg/fetch/pull/1369 |
| 12:56 | <hsivonen> | sideshowbarker: Looks like it was good not to update log4j to 2.x. (So far, it looks like the 1.x RCE that I'm aware of doesn't apply.) https://twitter.com/tbroyer/status/1470024270852014086 |
| 13:25 | <annevk> | mek: so foolip has approved the FS PR, but I'd like your take as well; do you think you can get to it this week? |
| 20:18 | <sideshowbarker> | sideshowbarker: Looks like it was good not to update log4j to 2.x. (So far, it looks like the 1.x RCE that I'm aware of doesn't apply.) https://twitter.com/tbroyer/status/1470024270852014086 |
| 21:41 | <Mattias Buelens> | Bikeshed complains that it finds two specs that define the EDIT: Answered, thanks Domenic! 🙂 |
| 21:44 | <bkardell> | I just invited Eric Meyer here - Eric is trying to help figure out what to specifically put in a PR for HTML re: directionality and shadow Dom - it's currently in the last comment of https://github.com/whatwg/html/issues/3699#issuecomment-988890095 - can someone have a look and direct him toward how to get a PR or edit? / Domenic or annevk maybe? |
| 21:44 | <Domenic> | What's the question? Is it how to send PRs to HTML? |
| 21:45 | <bkardell> | I think it is whether what he written makes sense to send as a PR? |
| 21:48 | <Domenic> | Oh, no, that didn't seem like a spec to me. I think the idea is to modify https://html.spec.whatwg.org/#the-directionality and maybe https://html.spec.whatwg.org/#directionality-of-the-attribute and maybe https://html.spec.whatwg.org/#rendering |
| 21:48 | <bkardell> | that's helpful, ta |
| 22:18 | <Eric Meyer> | I’ll work on doing that, but in the meantime, it would be great to know if anyone has questions/comments/objections on the text that was posted. Or even thumbs-up/thumbs-down from members. |
| 22:18 | <Eric Meyer> | I can take thumbs-up as being satisfied with what the comment says, and thumbs-down I can follow up on to find out what concerns there are. |
| 22:20 | <Domenic> | Well, I don't really understand it well enough to comment :). I guess it seems like the main content is the nested 6th bullet, and that will modify https://html.spec.whatwg.org/#the-directionality ? That seems like a lot less spec than what Fantasai proposes in her comment, but maybe it's just a really short statement of it. |
| 22:20 | <Domenic> | My plan is to do editorial review only, and delegate normative spec review to people like Fantasai or the Chrome rendering team who understand this stuff better. |
| 22:22 | <Domenic> | I guess also the 5th bullet indicates that there'll be a big change of most of #the-directionality from using tree relations (e.g. "parent element") to using flat tree relations, as well? |
| 22:24 | <Eric Meyer> | I think it’s basically the same, with that one exception. Shadow DOM directionality and language inheritance should be essentially “flatten the tree, then act as described in https://html.spec.whatwg.org/#the-directionality, except for this one exception with slots and hosts when the slot has no actual content”. |
| 22:25 | <Domenic> | Well, what we need is a spec for determining "the directionality of an element"; I don't see how you'd insert "flatten the tree" into that. |
| 22:25 | <Domenic> | I.e. we're not re-determining the directionality of the entire document tree every frame |
| 22:25 | <Domenic> | We need a mechanism for computing the directionality of a specific element when asked. |
| 23:19 | <devsnek> | was there ever any discussion about combining urlpattern instances? i don't see anything on github. if this isn't dumb i might open an issue |