| 05:11 | <annevk> | Domenic: excluding control code points is quite typical |
| 05:12 | <Domenic> | But this infects the [^] syntax it appears: https://www.w3.org/TR/xml/#sec-notation |
| 05:12 | <Domenic> | As well as just the [] syntax in general |
| 05:12 | <Domenic> | So it looks like XML-defined EBNF is just not really usable? |
| 05:13 | <annevk> | Oh great, I didn't realize that ☹️ |
| 05:15 | <Domenic> | How do we feel about JS-compatible RegExps... The other main alternative is to just write a parser algorithm |
| 05:15 | <Domenic> | Or maybe https://www.rfc-editor.org/rfc/rfc5234 |
| 05:59 | <annevk> | Domenic: I think writing it out in prose might not be so bad |
| 06:00 | <annevk> | Domenic: if you turn the code point sets into Infra-style definitions and then have a validating algorithm that says "if string is not a X followed by zero or more Ys" and such |
| 09:15 | <zcorpan> | What's the status of removing sync XHR? https://github.com/whatwg/xhr/issues/20 |
| 12:18 | <Noam Rosenthal> | annevk any chance to continue review on https://github.com/whatwg/fetch/pull/1413 at some point? yutakahirano has already given it a 👍️ |
| 14:22 | <raphaellouis> | Hi all! Can someone help me? |
| 14:23 | <raphaellouis> | I have a question, if anyone can answer I would be happy |
| 14:32 | <raphaellouis> | I would like to know if we could create a library in javascript to generate user interaction data |
| 14:32 | <raphaellouis> | This would be an alternative to cookies etc. |
| 14:33 | <raphaellouis> | This can be interesting for data analysis etc |
| 14:33 | <raphaellouis> | concept: https://discourse.wicg.io/t/draft-idea-spec-proposal-an-interesting-open-free-libre-proposal-for-a-scalable-sustainable-secure-private-accessible-business-model-compared-to-alternatives-such-as-topics-cookies-flocs-and-other-user-tracking-technologies/5906/3 |
| 14:35 | <raphaellouis> | I would like to know if this idea is good or bad, I want to hear all sides, all criticisms, everything that can be improved or corrected |
| 14:45 | <raphaellouis> | Everything I've written is still conceptual, draft |
| 15:37 | <annevk> | Noam Rosenthal: ah, from the title change I guess you have made a change in approach now |
| 15:38 | annevk | notices Domenic's comment there about formatting |
| 15:38 | <Noam Rosenthal> | annevk: yes, as we talked about, there's no longer a "conclude" call and fetch reports timing automatically, except for in the case of navigation and early-hints |
| 15:39 | <annevk> | I really wish someone would write a Bikeshed source code formatter we could use, ideally mostly compatible with existing conventions to not mess up blame too much |
| 15:39 | <Noam Rosenthal> | ... accompanied by the HTML PR https://github.com/whatwg/html/pull/7722 |
| 15:39 | <Domenic> | Source code formatter is on my list of "learn Rust" projects. Seems... unlikely to happen. |
| 15:40 | <Noam Rosenthal> | I really wish someone would write a Bikeshed source code formatter we could use, ideally mostly compatible with existing conventions to not mess up blame too much |
| 15:58 | <annevk> | Noam Rosenthal: so I'm not sure what's happening with the review-resolve cycle but I'm finding the same issues as Yutaka it seems, e.g., timing global seemingly having an unaccounted null value; except this specific Yutaka issue was marked as resolved (whereas some others were not but do appear addressed) |
| 16:00 | <annevk> | Noam Rosenthal: as for the formatter, essentially something that takes a WHATWG-style *.bs file, parses it, and then serializes it according to the rough formatting guidelines in README.md |
| 16:00 | <annevk> | Domenic might have more informed thoughts 🙂 |
| 16:01 | <Domenic> | Yeah, no open issue. It's hard because parsing/serializing bs (or Wattsi-style HTML) is not an identity function. |
| 16:01 | <annevk> | I guess Yutaka also r+'d it and there was no forced rebase so hmm |
| 16:02 | <Domenic> | Another problem with HTML formatters is that it's hard to know what whitespace is significant. E.g. HTML Tidy often creates foo.\n</p> which is undesirable by our standards. |
| 16:03 | <Domenic> | But like <li>\n<p> is technically different than <li><p>(different DOM structure, with a text node in the middle for the former) but we consider them both OK |
| 16:04 | <Noam Rosenthal> | Noam Rosenthal: so I'm not sure what's happening with the review-resolve cycle but I'm finding the same issues as Yutaka it seems, e.g., timing global seemingly having an unaccounted null value; except this specific Yutaka issue was marked as resolved (whereas some others were not but do appear addressed) |
| 16:05 | <annevk> | Noam Rosenthal: as written fetch's timingGlobal argument is either "client" or a global object afaict (though the usage side suggests "none" can be valid and the algorithm suggests null can be valid) |
| 16:06 | <annevk> | Domenic: you need to push something for https://github.com/whatwg/dom/pull/1079 |
| 16:06 | <Noam Rosenthal> | Noam Rosenthal: as written fetch's timingGlobal argument is either "client" or a global object afaict (though the usage side suggests "none" can be valid and the algorithm suggests null can be valid) |
| 16:07 | <annevk> | Noam Rosenthal: to be clear I think it would be better if you made that "none" for consistency with "client" |
| 16:07 | <annevk> | Noam Rosenthal: if we're doing enum or object let's not also add null to the possible types |
| 16:07 | <Noam Rosenthal> | Noam Rosenthal: to be clear I think it would be better if you made that "none" for consistency with "client" |
| 16:08 | <Noam Rosenthal> | I usually prefer whims |
| 16:08 | <Noam Rosenthal> | Enums |
| 16:09 | <Domenic> | Domenic: you need to push something for https://github.com/whatwg/dom/pull/1079 |
| 16:21 | <Noam Rosenthal> | annevk: fixed comments. re. request vs. fetch: the idea is that all timing-related things are associated with fetch and not with a request. So if the request is forwarded by a service worker the timing info, initiiator and reporting global relate to the service worker and not to the original fetcher |
| 16:23 | <annevk> | Noam Rosenthal: does that mean we need to change the fetch params when we hand it over to the SW? |
| 16:24 | <Noam Rosenthal> | annevk: no need. new fetch params are created when the SW calls fetch() |
| 16:24 | <annevk> | Noam Rosenthal: well yes, if it does that, but that's also the case for bits on request so I'm not sure how that's an argument for this setup |
| 16:26 | <Noam Rosenthal> | annevk: you mean the TAO bit etc.? I think they should also move to fetch-params |
| 16:26 | <Noam Rosenthal> | also those are a bit different because they're not passed from the outside |
| 16:28 | <Noam Rosenthal> | To me it seems cleaner if the request was something somewhat immutable and transient that kind of matches with the Request object, and doesn't need to be "reset" when forwarded by the SW. In the case of timing though, it currently doesn't really have any observable difference |
| 16:31 | <Noam Rosenthal> | currently we keep bumping into these issues of ambiguity between request and fetch-params, I'm hoping that by making request somewhat immutable & transient we can avoid them, but maybe it's hard to accomplish because of thing's like request's client |
| 16:34 | <Noam Rosenthal> | annevk: but if you think it's preferable to make timingGlobal& initiator request-associated I could go with it, it keeps the current separation of fetch taking a request + callbacks as parameters |
| 16:52 | <annevk> | Noam Rosenthal: so to me the string field seems very similar to "destination" (and should probably be an enum like it) |
| 16:52 | <annevk> | Noam Rosenthal: and longer term we want to figure out how they relate going forward |
| 16:53 | <annevk> | Noam Rosenthal: I'm less sure about the other fields and I do like the idea of moving some stuff out of request as it's quite overloaded |
| 17:03 | <Noam Rosenthal> | annevk: ok, I will move both to being request-associated. Maybe changing it to an enum is more involved though for this patch, an initiator type could potentially be any element name |
| 17:03 | <annevk> | I see, yeah, please file a follow-up? |
| 17:03 | <Noam Rosenthal> | annevk: I forget, in the case of iframes, is request's client the container or the reserved environment of the iframe? If it's the former I can probably do away with timingGlobal |
| 17:05 | <annevk> | Noam Rosenthal: hmm, that's a very good question; I'm not sure |
| 17:05 | <Noam Rosenthal> | (the code in HTML for that is a bit hard to follow) |
| 17:05 | <annevk> | For the initial request you kinda need both I think, but I'm not sure what is written down and whether that maps to what implementations do |
| 17:06 | <annevk> | As in, you need the parent for referrer thingies, but you don't want the parent for SW selection, say |
| 17:14 | <Noam Rosenthal> | annevk: yea both are passed, and the client is the container. https://html.spec.whatwg.org/#process-a-navigate-fetch |
| 17:14 | <Noam Rosenthal> | (2) |
| 17:15 | <Noam Rosenthal> | annevk: it means that I can do away with timingGlobal - it's always client, and in the early hints case request's client is a reserved environment which doesn't have a global object, I can infer that instead of pass it from outside |
| 17:16 | <Noam Rosenthal> | for the cases where there are no reporting (e.g. cross-origin style subresources) initiatorType can be null or do not report etc |
| 18:21 | <Noam Rosenthal> | annevk: done, though currently fetch doesn't build due to some biblio thing? |
| 18:57 | <sefeng> | Yoav Weiss: For this test https://github.com/web-platform-tests/wpt/blob/master/largest-contentful-paint/initially-invisible-images.html, wouldn't you expect an green-1x1.png entry first and then the yellow.png one? |
| 19:22 | <Yoav Weiss> | @sefeng: According to the spec, I think you're right and that's what I'd expect, because "potentially add an LCP entry" is called after the image is loaded |
| 19:26 | <sefeng> | Okay, yeah, that assertion is going to fail for non “yellow” images, I’ll make some changes to the test |
| 19:27 | <Yoav Weiss> | Thanks! |