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? |
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? |
21:20 | <Dominic Farolino> |
Do you mean post-insertion steps? |
21:46 | <Dominic Farolino> |
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:
Please see https://gist.github.com/domfarolino/83b1a436c5ad4fc68b04aa0092985f58 and run this in the console in Chrome (Firefox does not synchronously fire 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) |