Mirko Brodesser

> Yes, implementations run steps after as well. > Things chromium does before removal: > > Hides popovers > Fires sync mutation events > Cleans up Range instances > >...

> Except for popover we handle all of those in DOM directly. @annevk: what does "in DOM directly" mean?

An alternative idea: when https://html.spec.whatwg.org/#hide-popover-algorithm is invoked, instead of invoking https://html.spec.whatwg.org/#check-popover-validity from there, check only if https://html.spec.whatwg.org/#popover-visibility-state is "hidden" and if so return early. Be aware that https://html.spec.whatwg.org/#popover-visibility-state is set...

> I see, yeah I guess that in the case where we want to hide a popover regardless of the dom state, the only relevant check in the check popover...

> However, https://jsfiddle.net/hyzLu4nk/1/ doesn't throw in Chrome dev edition. Given https://github.com/whatwg/html/pull/9142#issuecomment-1538596372, it seems to make sense to specify that. @josepharhar WDYT? @nt1m would you support specifying this? Locally I've a...

~~Given https://github.com/whatwg/dom/pull/1176 was merged, this can be closed?~~

> @mbrodesser-Igalia that's about attribute mutations, this is about tree mutations, so no? Yes. Wanted to post that in another ticket, sorry.

> Wrt to the CSP integration I can see value in a potential `trusted-eval` (name tbd) expression to replace `unsafe-eval`. This new value along with the existing trusted types directives...

According to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src#unsafe_eval_expressions it'd behave as a no-op.

Stumbled on https://github.com/web-platform-tests/wpt/issues/44352, which either needs to be fixed or worked around.