| 08:42 | <annevk> | Domenic: FYI: https://github.com/whatwg/dom/issues/1321 |
| 08:43 | <annevk> | Noam Rosenthal: I don't get the impression he feels strongly about it. One point that was raised is that moveBefore() won't be state-preserving for accessibility as layout will be impacted. |
| 08:48 | <Noam Rosenthal> | Noam Rosenthal: I don't get the impression he feels strongly about it. One point that was raised is that |
| 08:48 | <Noam Rosenthal> | Re firing the events - sounds good, let’s start without like we said at WHATNOT and we can revise based on community feedback. |
| 12:40 | <Andreas Kling> | Anyone with HTML parsing know-how able to tell me if I'm missing something here or if this template/foreignObject interaction indeed leads to bugs? :) https://github.com/whatwg/html/issues/10739 |
| 12:51 | <freddy> | Question about fetch metadata. It appears that all of the cases where page1.example is a) redirecting to page2.example, b) opening page2.example in a popup, c) navigating to page2.example - They are all done with Fetch Metadata of {sec-fetch-dest: document, sec-fetch-mode: navigate, sec-fetch-site: cross-site}. I wonder if it would be useful to have different or additional metadata for popups as they will include an opener reference (which the other cases don't). -- I am already fully aware that COOP exists which can control the popup case (but not make the browser tell beforehand) |
| 12:58 | <annevk> | Noam Rosenthal: well, in that we preserve state in the DOM tree, but for the a11y tree it'll be the same as remove/insert. |
| 13:00 | <annevk> | freddy: there's a popup proposal in the Fetch Metadata repo, been there since forever |
| 13:00 | <annevk> | Andreas Kling: I'll have a look, but your best bet would be hsivonen or zcorpan I suspect |
| 13:01 | <freddy> | annevk: great minds think alike, huh |
| 13:04 | <hsivonen> | Andreas Kling: Likely a spec bug |
| 13:05 | <Noam Rosenthal> | Noam Rosenthal: well, in that we preserve state in the DOM tree, but for the a11y tree it'll be the same as remove/insert. |
| 13:09 | <annevk> | Andreas Kling: given that it checks for a template element on the stack of open elements, I'm inclined to think that's inclusive of a namespace and therefore it wouldn't find any element |
| 13:09 | <annevk> | Andreas Kling: as whenever the HTML specification talks about elements that's about a particular identity derived from local name and namespace |
| 13:10 | <annevk> | hsivonen: ^^ |
| 13:11 | <hsivonen> | annevk: I recall there having been a bug on this theme previously. (Part of how the combination of the introduction of SVG on one hand and template on the other resulted in a bunch of bugs.) |
| 13:11 | <hsivonen> | annevk: But it's indeed possible that the spec language is defined in a way that implies the HTML namespace on the stack. |
| 13:34 | <Andreas Kling> | Ohhh, interesting! We've indeed implemented stack checks as "is this tag name present on the stack", but we're ignoring the namespace |
| 13:56 | <annevk> | I wonder if one could put something on the stack with a namespace prefix. I suspect not as the stack is controlled by the HTML parser. |
| 13:58 | <zcorpan> | I wonder if one could put something on the stack with a namespace prefix. I suspect not as the stack is controlled by the HTML parser. |
| 14:02 | <zcorpan> | Hmm, the inconsistency in the spec with when namespaces are explicit isn't ideal. See https://html.spec.whatwg.org/#has-an-element-in-scope (and the next few "in foo scope" definitions) |
| 14:03 | <zcorpan> | Andreas Kling: https://html.spec.whatwg.org/#xml
|