| 06:21 | <annevk> | Yagiz Nizipli: that's probably because Chromium was also the initial implementer. They are not always careful to ensure the tests match the specification. I've run into this a couple of times as well. |
| 06:22 | <annevk> | I'm surprised you're the first one to run into this however as there were also other implementers reportedly with a different URL stack. |
| 06:31 | <Yagiz Nizipli> | annevk: So, what do you recommend going forward? Should I open a PR to WPT to remove this, or should the spec be changed? |
| 07:11 | <annevk> | Yagiz Nizipli: assuming it's indeed a bug the test should be aligned with the specification. If Chromium (or anyone) has concerns about aligning with the specification that can then be a separate discussion after which the test could in theory be changed back. I hope that Jeremy or Shunya will get back to you relatively quickly. If not, I'm happy to take a look early January. |
| 07:12 | <annevk> | Generally though we don't want to remove coverage, especially if it led to discovery of some interoperability issue. |
| 07:20 | <Yagiz Nizipli> | By the way, it seems Deno’s implementation also parses the port number to unsigned integer to pass it to URL port setter. |
| 07:27 | <annevk> | Luca Casonato: ^^ |
| 07:39 | <Luca Casonato> | By the way, it seems Deno’s implementation also parses the port number to unsigned integer to pass it to URL port setter. |
| 10:14 | <黄宏杨``0111 y_y L0VE r_r> | Wash world win |
| 12:15 | <Yagiz Nizipli> | Oh we do? Can you file a bug? |
| 13:06 | <smaug> | annevk: FWIW, it isn't super clear to me how customElements would be propagated through nested Elements. Would a child get one from parent? |
| 13:06 | <smaug> | What if child is then moved to be a child of another element which uses different registry |
| 13:07 | <smaug> | (I'm rather worried about extra memory use here, if all the elements need to keep track of stuff) |
| 13:53 | <annevk> | smaug: you'd likely need some extra bits on element and additional bookkeeping when removing an element to keep it all efficient, yeah |
| 13:53 | <annevk> | smaug: but the idea is that once a registry is assigned to a node, it can't be unassigned |
| 13:54 | <smaug> | Is the idea also that if parent has registry, and then you do parent.innerHTML = "<div>", that div would get parent's registry? |
| 13:54 | <annevk> | Yes |
| 13:55 | <smaug> | if so, wouldn't all the elements get registry from document, well, window? |
| 13:55 | <smaug> | or is that somehow special |
| 13:55 | <annevk> | In a document with a browsing context, yes. |
| 13:56 | <smaug> | So all the elements would then need to keep track of the global registry in case they are attached later to another parent element which isn't bound to browsing context but has different registry ? |
| 13:57 | <annevk> | That's the model, that's probably not how you'd want to implement it. |
| 13:58 | <annevk> | Assuming that with "all the elements" you mean all the elements in a document with a browsing context. |
| 13:58 | <smaug> | right |
| 13:58 | <smaug> | so, I think I'm not too happy with this |
| 13:58 | <smaug> | too much overhead |
| 13:59 | <annevk> | We thought so too, but we found a way to make it work. |
| 14:01 | <smaug> | One may optimize certain cases out, like having just a flag for the global registry |
| 14:02 | <smaug> | but eventually when adopting to a new document or so, a link to the registry needs to be there |
| 14:02 | <annevk> | You can have that in a side table too |
| 14:03 | <smaug> | The side table needs to still have a pointer for the element |
| 14:04 | <smaug> | (and finding the registry from a side (hash)table isn't exactly free) |
| 14:05 | <smaug> | However, I do like the aspect that this all wouldn't be so bound to shadow root |
| 14:51 | <smaug> | In which all cases registry would be propagate from parent to child? Whenever it is set? I mean, when adding a child to parent, in which case child would get its registry set based on what is in the parent? |
| 14:55 | <annevk> | Part of the background btw is the discussion in https://github.com/WICG/webcomponents/issues/1040 and https://github.com/WICG/webcomponents/issues/1043. People wanted disconnected elements from a scoped registry to still have sensible behavior and also get rid of the shadow root requirement. |
| 14:57 | <annevk> | Connected insert and the HTML parser are the main places that do it. |
| 14:57 | <smaug> | I wonder why connectedness matter |
| 14:58 | <annevk> | Maybe that can be dropped? I put it in the same branch as we do upgrades, but perhaps that's wrong. |
| 14:59 | <annevk> | I don't think this WHATNOT call is the place to do it, but I'd love a call with you and rniwa and whoever else is interested and we go over the PRs line-by-line. |
| 14:59 | <annevk> | But that will have to be in Jan. |
| 14:59 | <smaug> | hmm, and HTML parser? Does it mean that if I create an element and set its registry, and then create another element and add it as a child, the child won't get registry, but if I do parent.innerHTML = "<div>"; then the element gets registry? I guess no, since innerHTML goes via DocumentFragment in the spec |
| 15:00 | <smaug> | annevk: sounds good, the meeting 🙂 |
| 15:04 | <annevk> | smaug: if you do innerHTML it will get the registry through the context element. If you create an element yourself, you always have to be conscious about where you create it to end up with the right registry. That's why registries will expose createElement() though perhaps it should be just create() I was thinking the other day as "element" in that name is kinda redundant: customElements.createElement() |
| 15:05 | <annevk> | Generally whenever there's "looking up a custom element definition" it now needs to be preceded by a "looking up a custom element registry" and then instead of a document we pass that registry to the former (which will return early if the registry we found is null) |
| 15:05 | <smaug> | I like create() |
| 16:36 | <Yagiz Nizipli> | It seems there are more issues with URLPattern web-platform tests. I'm putting them to the issue, but I've failed to understand why new URLPattern({ "pathname": "/(\\m)" }) fails on Chromium? Is there a specific spec code that I'm missing or is this a bug as well? https://github.com/whatwg/urlpattern/issues/239 |
| 17:26 | <sideshowbarker> | Do we need a new editor for the Service Workers spec? |
| 19:06 | <annevk> | It would be good to have a more active maintainer. |
| 20:15 | <Noam Rosenthal> | I'm happy to help with reviews there, I feel I know it pretty well by now though I'm not actively working in that area much nowadays |
| 23:27 | <Domenic> | I think we could recruit one of my colleagues from Tokyo as a service worker editor |