00:05 | <Domenic> | javascript: URL navigation is just a normal navigation I believe. It's a new Window, and a new Document. |
08:59 | <keithamus> | annevk: WPTs for revamped scoped custom elements test Element customElementRegistry - but the spec IDL has Element customElements - which one is the most up to date? Was this the compat issue? |
09:00 | <keithamus> | nvm, looks like I answered my own question looking at https://github.com/web-platform-tests/wpt/commit/1b4c64d41f2b8f41b7b6215900eaf63e2e8a9f94 |
09:56 | <annevk> | jmdyck: thanks, that's fixed now. |
09:57 | <annevk> | LI Daobing: file an issue against whatwg/html on GitHub. Also linked from the top of https://html.spec.whatwg.org/multipage/ |
09:58 | <annevk> | keithamus: which specification PR still has customElements ? I thought I had updated all of that quite a while back. |
09:59 | <keithamus> | I think it's actually just the comment: https://github.com/whatwg/html/issues/10854#issue-2735341285 |
10:00 | <annevk> | Oh, well please don't implement based on that. |
10:00 | <keithamus> | I was just stubbing out the necessary APIs based on it |
10:01 | <annevk> | Oh no. Well, I'll update it, but please don't do that again. We really need implementers to implement based from the specification drafts. |
14:20 | <Maxim Vaarwel> | What example satisfies it? I tried many ways and none of them worked. The rules for choosing a navigable
|
15:51 | <Shima Ryuhei> | Hey, I have a question about this part of the Streams spec. In the spec, there's this assertion during return():
But it seems like this assumption can be broken if you call return() directly before the previous next() settles. Here’s a minimal example:
This was originally raised in Node.js here: In this section of the Web IDL spec, should the return method call the asynchronous iterator return steps only after the previous next call has settled? Or am I missing something? |
16:10 | <zcorpan> | Hmmm. The test uses the initial about:blank document and then sets src , which is a case where Window is not replaced ( https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13663 ). But even when navigating from a document that is not the initial about:blank, I get window reuse when navigating to a javascript: URL, see https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13662 |
16:13 | <zcorpan> | The first case is https://html.spec.whatwg.org/#initialise-the-document-object:~:text=If%20browsingContext%27s%20active%20document%27s%20is%20initial%20about%3Ablank%20is%20true%2C%20and%20browsingContext%27s%20active%20document%27s%20origin%20is%20same%20origin%2Ddomain%20with%20navigationParams%27s%20origin%2C%20then%20set%20window%20to%20browsingContext%27s%20active%20window%2E |
16:15 | <zcorpan> | The javascript: case is https://html.spec.whatwg.org/#the-javascript:-url-special-case which creates a Document (if a string is returned) but I'm not sure now if it says to reuse the window |
16:49 | <zcorpan> | Wait, === will compare the WindowProxy, right? How do I tell if the Window was replaced? |
17:41 | <zcorpan> | https://chromium-review.googlesource.com/c/chromium/src/+/804797/5/third_party/WebKit/LayoutTests/external/wpt/html/browsers/the-window-object/reuse-across-navigation/same-origin.html uses an expando, which makes sense, but I couldn't get that to work in live dom viewer. Maybe the issue is testing in live dom viewer |
18:29 | <Maxim Vaarwel> | annevk Dominic Farolino could you help me? |