| 06:59 | <annevk> | Nice visualization! That does indeed seem to strongly argue for making source a twin of relatedTarget and making the relevant dispatch calls that have a source also make the event composed. |
| 07:27 | <Alice (🇳🇱)> | As long as it's not a deal breaker for folks to have the event bubble to the shadow roots in between |
| 07:27 | <Alice (🇳🇱)> | Jake Archibald might have more of an idea there, as would dandclark (who is presumably not awake right now) |
| 07:28 | <Alice (🇳🇱)> | It was honestly quite a surprise to me that relatedTarget has the effect of seemingly overriding composed once you reach the common ancestor root |
| 07:40 | <smaug> | now, with submit, can submitter be null? Since if yes, then I guess in such case event shouldn't be composed. So maybe some of these events should have .composed = source || submitter || <foo>; |
| 07:48 | <Alice (🇳🇱)> | submitter sets source, right? |
| 07:48 | <Alice (🇳🇱)> | https://github.com/whatwg/html/pull/10995/changes#diff-41cf6794ba4200b839c53531555f0f3998df4cbb01a4d5cb0b94e3ca5e23947dR64995 |
| 07:50 | <smaug> | Right, but I mean this. |
| 07:53 | <smaug> | And since dom spec uses relatedTarget as a concept, not attribute value, we could just say that source/submitter/etc are the relatedTarget concept, just the same way .relatedTarget is in some events |
| 07:55 | <Alice (🇳🇱)> | what about it, sorry? |
| 07:56 | <Alice (🇳🇱)> | i.e. replace the proposed "source" concept with just reusing the "related target" concept? |
| 07:57 | <smaug> | I meant just that submitter can be null. And since it can be null and we want to avoid breaking sites too badly, we probably want to keep submit event not-composed when submitter is null so that the event doesn't start to propagate to light dom unexpectedly |
| 07:58 | <smaug> | right. Would that work? |
| 08:00 | <Alice (🇳🇱)> | I'm confused on a couple of things:
|
| 08:42 | <annevk> | smaug: jarhar: I think for option elements in theory we could use the content property, but nobody supports that on elements with non-image values? |
| 09:14 | <Luke Warlow> | This would be a useful feature for other appearance base things (e.g. ::file-selector-button) but it's probably a big lift? |
| 09:21 | <emilio> | We had an implementation of that and it was not web compatible |
| 09:21 | <emilio> | But maybe for options we could make it work, or so |
| 09:23 | <Luke Warlow> | But tbf for options it would only be UA styles that needed it right? That should be more compatible. Not saying it's the right thing to do, shadow dom seems probably fine? |
| 09:32 | <smaug> | FYI for random readers, the proposal got documented here https://github.com/whatwg/html/pull/10995#issuecomment-4572681552 |
| 11:38 | <annevk> | smaug: https://github.com/whatwg/dom/pull/1469 BoundaryPointsRange mixin; this was easier than expected |
| 11:43 | <smaug> | ah, that way. Well, it changes getter inheritance |
| 11:43 | <smaug> | If that matters |
| 15:56 | <dbaron> | For long-lived PRs against HTML, is there a preference (and is it a strong one) for rebase versus merge versus don't-update-to-main? (That said, I think I will probably need to update the menu-elements branch to main in order to use things that aren't in the spec at the original branch point.) |
| 16:01 | <annevk> | dbaron: strong preference for rebase + fixup commits, and rebase incl. squash for the bits you know the reviewer already looked at (this latter thing is a bit trickier and maybe not as needed, but it might make rebase easier) |
| 16:01 | <annevk> | I find that merge commits make it very hard to deal with PRs and figure out what their state is relative to main. |
| 16:02 | <annevk> | That said, we've made all variants work to some extent I think so maybe "strong" is a bit much. |