13:20
<freddy>
is there a way to style a popover (or a popover's children) that they become visible? I guess overriding the user-agent sheet "display: none" for a popover isn't possible. But not even for the children?
14:08
<Luke Warlow>
is there a way to style a popover (or a popover's children) that they become visible? I guess overriding the user-agent sheet "display: none" for a popover isn't possible. But not even for the children?
Why is that not possible? I thought you could just say "display: block" and it would show?
14:12
<freddy>
Mh, not for the children. <div popover style="display:block"><h1>test shows the div with the h1 child but <div popover><h1 style="display:block;">test doesnt. I guess that's sort of intentional and I get it. I just wonder what kind of override there is
14:12
<freddy>
I tried adding !important and visibility: visible for good measure ;)
14:21
<annevk>
freddy: that would still put display:none at the top of the subtree and that wins
14:21
<annevk>
freddy: so you need to change that too, perhaps display:contents is what you're after?
14:28
<freddy>
<small>perhaps I don't get CSS specificity </small>
14:42
<annevk>
It's not about specificity, it's cascade
14:42
<annevk>
Maybe not even that, as I guess it's not really inherited
14:49
<emilio>
Yeah is just that display: none is not overridable on descendants
19:01
<TabAtkins>
Yup, nothing about popover is special here. display: none on a container prevents the container and all of its contents from generating boxes at all, with no override possible on the descendants. (After all, what would that mean?)
21:19
<Dominic Farolino>
Dominic Farolino: actually, I don't know how the insertion step model works in case of mutations. Say, you have an element and it has 3 child elements. That subtree root element is inserted to document tree. Now child 1 has insertion steps which run some script which removes the child and adds it to be the last of the child nodes. So child list is now 2, 3, 1. Do the insertion steps get run on 1 again, because it is now after 2 and 3?
I'm just seeing this now because this website was unloaded in my Chrome and the freaking favicon didn't give me updates that I had a ping, sorry!
21:20
<Dominic Farolino>

Now child 1 has insertion steps which run some script

Do you mean post-insertion steps?

21:46
<Dominic Farolino>

Do the insertion steps get run on 1 again, because it is now after 2 and 3?

Yes they do, and the PR answers this.

I'll assume every instance of "insertion step" in your message is "post-insertion step". With that edit, here's what happens:

  1. Insertion steps would run for the root, and its three children, in tree order, never running script.
  2. Post-insertion steps would run for the root, and its three children, in the same order.
  3. Say the first child is an about:blank iframe with an onload handler. This handler is synchronously invoked (for child 1) during its post-insertion steps (that's how iframes work; the initial about:blank iframe fires load syncly).
  4. The event handler removes the iframe from the DOM, and re-inserts it after its siblings.
  5. This re-enters the DOM insertion algorithm, which synchronously re-enters its post-insertion steps, and re-invokes the onload event for the same iframe element. This runs the event handler re-entrantly.

Please see https://gist.github.com/domfarolino/83b1a436c5ad4fc68b04aa0092985f58 and run this in the console in Chrome (Firefox does not synchronously fire onload for about:blank iframes IIRC).

Note that post-insertion steps do not intend to solve re-entrant event handlers by forcing their order to be broken or anything. They only ensure that by the time script runs in them, the batch of relevant DOM mutations (associated with the insertion) are all complete.

21:47
<Dominic Farolino>
smaug for above
21:49
<smaug>
step (2) is unclear
21:50
<smaug>
why it iterates them in 1, 2, 3 and not 1, 2, 3, 1 ? (since step (3) moves 1 to be after 3)
21:51
<smaug>
(Note, script runners don't have this issue, since the post-insertion steps is just a queue )
21:54
<smaug>
In other words, how does the PR ensures that post-insertion steps aren't run 3 times for the child element, which is inserted to document only twice?
21:55
<smaug>
(Script runners avoid this issue by queuing the post-insertion operations)
22:17
<smaug>
Isn't the PR missing https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/container_node.cc;l=430?q=container_node.cc
22:19
<smaug>
and https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/container_node.cc;l=363;drc=0ebe2cf9f3f6544ba582473c5b9b8e3506f29708?q=container_node.cc
22:19
<smaug>
(seems complicated and less flexible vs script runners)