| 01:06 | <Garv> | iframes should be an empty element |
| 03:49 | <sideshowbarker> | annevk: (or anybody else familiar with the Fetch API who might have a few minutes), about the part of the diff at https://github.com/mdn/content/pull/40643/files which adds an additional Is that additional caching step at that point actually necessary or useful in practice? |
| 03:51 | <sideshowbarker> | Or to put it more simply, is that actually the recommended way to use the API? (The way that MDN should be showing developers to use it) |
| 04:22 | <Garv> | no like seriously, in todays era there's essentially no chance iframes don't run on a browser, and since the only purpose of iframes being full elements was to display an error message, nowadays they should be empty |
| 06:53 | <annevk> | sideshowbarker: I'm not sure. Jake Archibald would know. Or you could look at the service worker WHATWG uses. Hopefully that follows best practice somewhat. |
| 10:23 | <Jake Archibald> | sideshowbarker: I've replied |
| 10:23 | <sideshowbarker> | Excellent — thanks much |
| 10:25 | <Jake Archibald> | Garv: that's ideally true for a lot of elements. I mean, ideally, /> would have been meaningful outside of foreign content. The problem is, it's not something that can be changed about the platform now without severe breakages. Here's some history https://jakearchibald.com/2023/against-self-closing-tags-in-html/ |
| 10:27 | <smaug> | keithamus: I could be wrong, but I think this doesn't work if the relevant nodes are in shadow DOM (related to popovers inside buttons) |
| 10:28 | <smaug> | because of https://dom.spec.whatwg.org/#dispatching-events:~:text=true%3A-,Set,event%2E |
| 10:28 | <Jake Archibald> | Garv: Specifically, what would you do with the examples of <iframe src="…">fallback</iframe> in the wild? According to your suggestion, the "fallback" would be rendered. Eg see this example. You see "Fallback" on the page there as a direct consequence of <img> being an empty element - it can't have insides, so the "Fallback" is outside of it. Essentially, the </img> is ignored. |
| 10:28 | <smaug> | Prove me wrong 🙂 |
| 10:29 | <keithamus> | hmm |
| 10:29 | <smaug> | I couldn't immediately find tests using shadow DOM |
| 10:30 | <smaug> | for this stuff |
| 10:32 | <keithamus> | how does one have a popover inside of a shadowroot referenced through the button though? |
| 10:33 | <keithamus> | As in: Doesn't work because |
| 10:34 | <smaug> | keithamus: I was thinking the case when both button and popover are inside shadow dom |
| 10:35 | <smaug> | under the same shadow root |
| 10:41 | <keithamus> | Okay so data:text/html,<div><template shadowrootmode=open><button id=b popovertarget=p>Open<div popover id=p></div></template></button></div> works in Chrome but not with this patch, so they must do something different to the spec I suppose? |
| 10:44 | <keithamus> | https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/forms/html_form_control_element.cc;l=440-446?q=html_form_control_element.c 🤔 |
| 10:54 | <smaug> | I wonder what rawtarget is |
| 10:54 | <smaug> | is that something which isn't cleared? |
| 10:57 | <keithamus> | https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/events/event.h;l=150-152?q=event.h indeed |
| 10:59 | <keithamus> | I'm confused though, it's the exact same code as target(), and SetTarget() doesn't look to do anything particularly special |
| 11:01 | <smaug> | hmm |
| 11:08 | <keithamus> | seems like a simpler way to resolve this might be to mark the default handled for an element that is a popover, so that by the time it propagates to the button click it would just ignore the click |
| 11:08 | <keithamus> | but I suppose the button might do something other than popovertarget... though I'm not sure that's warranted even |
| 11:09 | <keithamus> | For example if you had a popover in a submit button, should clicking the popover submit the form? |
| 11:20 | <Noam Rosenthal> | Jake Archibald: are you planning to join WHATNOT tomorrow morning? I thought we could put patching on the table including some of the issues you've already raised around it |
| 11:20 | <Noam Rosenthal> | (it was discussed a few weeks back but attendance was low) |
| 11:21 | <Jake Archibald> | Noam Rosenthal: yeah, I'm up for that. I've not attended WHATNOT before. What's the best way to track it? |
| 11:22 | <Jake Archibald> | (it might clash with my onboarding stuff, but I'll take a look) |
| 11:22 | <Noam Rosenthal> | To be added to meeting invites? I'm not actually sure... cwilso ? |
| 11:23 | <Jake Archibald> | Ah, I'll respond to https://github.com/whatwg/html/issues/11527 |
| 11:25 | <Jake Archibald> | Oh wait, actually morning. Hah, I'm so used to that meaning 'afternoon' for me. Yeah I can make that |
| 11:28 | <Noam Rosenthal> | Yup, I think we live at around ~25 minutes distance so timezone adjustments are less necessary :) |
| 11:29 | <keithamus> | https://github.com/whatwg/html/issues/11537 |
| 11:44 | <smaug> | keithamus: does it work for Gecko if you use mOriginalTarget ? |
| 12:14 | <smaug> | ...since I guess we don't end up clearing the target in this case, given that the final target is in light DOM |
| 14:07 | <keithamus> | smaug: it does indeed work. Fixed and added the requisite test case. |