| 07:08 | <annevk> | 짜요: all I know is that there's no standardized limit |
| 09:39 | <Yoav Weiss> | annevk: Can we move https://github.com/w3c/preload/issues/115 to HTML, now that the HTML integration is complete? I'm trying to archive the old rep |
| 09:39 | <Yoav Weiss> | o |
| 09:40 | <Yoav Weiss> | Actually, same question for the various "enhancement" issues |
| 09:47 | <annevk> | Yoav Weiss: that seems reasonable, we should maybe have a label for them then |
| 09:59 | <Yoav Weiss> | SG! |
| 14:53 | <Domenic> | Yeah I've been using "topic: link" for preload etc. but maybe something dedicated is helpful. "topic: resource hints"? |
| 15:46 | <annevk> | Is "topic: resource hints (preload)" too wordy? Would also be nice to add "topic: timing" to HTML |
| 16:17 | <Domenic> | Well resource hints also includes preconnect |
| 16:24 | <annevk> | Yeah I realize and maybe prefetch? It's just that preload comes up a lot and it would be nice to be able to search for one of them. Could make it (inc. preload) if wordy isn't a problem |
| 17:55 | <zcorpan> | annevk: how about topic: resource hints/preload |
| 18:41 | <Noam Rosenthal> | Domenic: hi, I want to try to find a good direction for the link header/element refactor |
| 18:43 | <Noam Rosenthal> | The way I was going was that all links are converted to the same "options" struct, either from a header or from an element, and then there is no need for each rel to do special header processing |
| 18:45 | <Noam Rosenthal> | ... but I can also go with having different "process header" and "process element" algorithms that end up funneling to functions like "preload" or "preconnect" |
| 19:26 | <Domenic> | Noam Rosenthal: so my main concern is the clarity of reading a given element's section. I am hoping: (a) it can be clear at a glance whether it supports elements/headers/early hints; (b) we move away from a defaults-and-overrides structure; (c) there is minimal duplication/maximal shared infrastructure. |
| 19:30 | <Noam Rosenthal> | Domenic: ok, for (c) - I think it would be good if the common "Process link headers" extracted something like the options struct from the headers, before sending it to the different rel sections |
| 19:31 | <Domenic> | +1 |
| 19:31 | <Domenic> | Options structs are good |
| 19:31 | <Domenic> | Just commented on the thread too |
| 19:32 | <Domenic> | (b) is mostly about fixing a preexisting problem but I think if we're doing (a) and (c) at the same time it's worth tackling (b) |
| 19:33 | <Noam Rosenthal> | ok, but without (b) and with options struct, how would you spell out the "process early hints" -> "handle headers for this type of link" transition? |
| 19:34 | <Noam Rosenthal> | at some points we went through a list of headers, and for each item we did something if it's defined for its rel |
| 19:35 | <Noam Rosenthal> | I guess by having "to handle headers for this type of link, do nothing" for each unsupported rel type? |
| 19:37 | <Domenic> | Yes exactly |
| 19:37 | <Domenic> | I think that's nice and super-obvious |
| 19:38 | <Domenic> | But we could also do something like "supported processing types" |
| 19:38 | <Noam Rosenthal> | sure I can go with that. Sometimes my natural tendency is more minimalistic (defaults) but it's not always the most obvious for readers |
| 19:39 | <Noam Rosenthal> | I think the "do nothing" duplication would be better than a list of supported types. It allows us to add new types without maintaining it in separate places |
| 19:39 | <Domenic> | Noam Rosenthal: probably-unrelated question, do I correctly recall you had some PR which removed "process response end of body" from navigation params? |
| 19:42 | <Noam Rosenthal> | Domenic: it was a PR that had many iterations (https://github.com/whatwg/html/pull/7531) and I believe you're referring to one of the iterations of the PR where we removed it and brought it back |
| 19:42 | <Domenic> | Hmm OK |
| 19:43 | <Domenic> | (I'm trying to make sure https://github.com/whatwg/html/pull/6315 stays up to date) |
| 19:43 | <Noam Rosenthal> | That navigation param was the cleanest way we found to report the iframe resource timing to the parent. There's no pending open PR that removes it (at least not one that I'm working on) |
| 19:44 | <Domenic> | Yeah I couldn't find one, so just wanted to double-check. No problem with keeping it. |
| 19:46 | <Noam Rosenthal> | Domenic: re the editorial I think I have enough to go on for tomorrow. If you think more comments add them to the issue and I'll see them in the morning? |
| 19:49 | <Domenic> | Sounds good, will leave any if I do! I think we have a good path. |