| 00:18 | <annevk> | domfarolino: don’t think so, I think the main problem is updating existing tests; |
| 00:18 | <annevk> | domfarolino: because of that it would be useful to have a browser with the fix |
| 00:19 | <annevk> | domfarolino: but maybe affected tests can be located with a couple greps |
| 01:07 | <domfarolino> | annevk: Ah that makes sense. I can take a look sometime this week assuming a patch to change default credentials behavior is fairly trivial |
| 01:08 | <annevk> | domfarolino: cool |
| 02:09 | <annevk> | JakeA: I suspect that for https://github.com/whatwg/fetch/issues/145 you'll have to find a new networking person given that tyoshino left |
| 04:16 | <annevk> | Domenic: happy to help figure out things for this API |
| 04:16 | <Domenic> | \o/ |
| 04:16 | <annevk> | Domenic: imperative slotting, that is |
| 04:16 | <annevk> | Domenic: I'm mainly wondering what developers would want to happen in various places |
| 04:17 | <Domenic> | Ah yeah. I was kind of hoping they would never mix styles, but developers sometimes surprise us. |
| 04:17 | <annevk> | Domenic: e.g., if you modify the children of a host element, is it fine that everything gets reset? |
| 04:17 | <annevk> | Domenic: should this allow elements that are not in a tree? (what if they get removed?) |
| 04:18 | <annevk> | Domenic: not connected I mean (everything is in a tree) |
| 04:18 | <Domenic> | Interesting, why would it get reset? |
| 04:19 | <annevk> | Domenic: that's how we redistribute; if something changes we assign things anew |
| 04:19 | <annevk> | Domenic: e.g., step 10 of https://dom.spec.whatwg.org/#concept-node-remove |
| 04:19 | <Domenic> | Maybe I am misunderstanding what you mean by "host element"? |
| 04:19 | <Domenic> | Right OK, an assigned element |
| 04:20 | <Domenic> | Not the whole shadow host |
| 04:20 | <annevk> | Hmm, I guess it's not quite connected either, but we require it to be a child of a host element atm |
| 04:21 | <Domenic> | Blah I should refresh my memory of this stuff |
| 04:21 | <Domenic> | It'd be nice to get some examples into the spec |
| 04:21 | <Domenic> | Some are trapped in the old spec |
| 04:23 | <annevk> | FWIW, I guess rniwa probably knew about this when he proposed this |
| 04:23 | <annevk> | So I suspect his stance here is that if you mutate the tree you'll have to deal with the consequences |
| 04:23 | <Domenic> | I am hopeful that is fine with developers |
| 04:23 | <annevk> | But would be good to make that clear with some examples around the API maybe |
| 04:23 | <Domenic> | Yeah exactly |
| 04:35 | <annevk> | Domenic: I think the main question we should answer is what happens if they are already assigned, and how do we update those other slot elements |
| 04:35 | <annevk> | Domenic: presumably we do want to fire slotchange at least |
| 07:11 | <annevk> | Domenic: it'd be more productive if you proposed something you have in mind in that issue |
| 07:12 | <Domenic> | annevk: I am not in favor of the feature in general, so I am not inclined to spend time on developing it. I am happy to give my constraints though. |
| 07:12 | <annevk> | Domenic: it just came to mind that built-ins don't have is="", but do have namespaces to consider, so their registry is different anyway |
| 07:13 | <annevk> | Domenic: it just seems so weird to suddenly insist built-ins be treated the same while there's no such consistency enforced elsewhere |
| 07:13 | <annevk> | Domenic: it appears you're just being arbitrary to stall things |
| 07:13 | <Domenic> | The problem is the same for both: the browser has a registry, and some frameworks can't deal with just constructors, so need some sort of side-table. |
| 07:14 | <Domenic> | I don't think it's arbitrary to insist we expose the primitives. |
| 07:14 | <annevk> | But as I've shown it's not the same primitive and it doesn't live in the same place |
| 07:15 | <annevk> | The primitive for custom elements lives on the custom element registry |
| 07:15 | <annevk> | The other primitive exists, but it's not layered in the same way at all |
| 07:15 | <annevk> | So insisting on the same API or solving them at the same time is arbitrary |
| 07:16 | <annevk> | We also don't have something.get(localname, namespace) that returns a constructor for built-ins |
| 07:16 | <annevk> | Why didn't you add that? Where is the consistency? |
| 07:19 | <Domenic> | Indeed, I'm saying we should add that |
| 07:20 | <Domenic> | The problem space needs to be considered holistically. |
| 07:20 | <Domenic> | If we're to address these frameworks which can't cope |
| 07:20 | <annevk> | But you haven't done that |
| 07:20 | <Domenic> | Indeed, I have not. I've only solved the important use cases so far. |
| 07:20 | <annevk> | Right, what's the problem with continuing to do so? |
| 07:21 | <Domenic> | The problem posed in the OP is the same for built-in elements and custom ones |
| 07:21 | <annevk> | I've looked at it holistically and I've outlined how all this could work, but we don't need to add all at once |
| 07:21 | <Domenic> | So we should not solve only half the problem |
| 07:23 | <annevk> | Right and as pointed out in the meeting and even by that person, it's not a problem for built-ins (also as shown by other issues) |
| 07:24 | <annevk> | I feel like we're going in circles... |
| 07:24 | <Domenic> | I don't agree it's not a problem for built-ins. For built-ins people keep a large table. |
| 07:24 | <Domenic> | They can do the same for custom elements |
| 07:24 | <Domenic> | But they don't want to |
| 07:27 | <annevk> | Domenic: okay, I guess I can try to solve this more generically; it is a little weird that ElementRegistry will have a different API shape from CustomElementRegistry |
| 17:12 | <railgun> | can whatwg definitions be used in the mdn glossary? in particular "insertion point" is a dead link but the whatwg definition is here https://html.spec.whatwg.org/multipage/parsing.html#insertion-point |
| 17:15 | <railgun> | mdn uses "(CC-BY-SA), v2.5 or any later version" so that should be compatible with CC-BY-4.0 (if they didn't say "or any later version" it wouldn't be compatible?) |